Date: Wed, 7 Jun 2000 17:03:52 -0500 From: Ade Lovett <ade@FreeBSD.org> To: Alexander Langer <alex@big.endian.de> Cc: David O'Brien <obrien@FreeBSD.org>, ports@FreeBSD.org Subject: Re: patches/ handling Message-ID: <20000607170352.F353@FreeBSD.org> In-Reply-To: <20000607205859.A16247@cichlids.cichlids.com>; from alex@big.endian.de on Wed, Jun 07, 2000 at 08:58:59PM %2B0200 References: <20000605184259.A21736@cichlids.cichlids.com> <20000606210209.B20037@dragon.nuxi.com> <20000607090533.D44242@FreeBSD.org> <20000607091405.A55268@dragon.nuxi.com> <20000607202517.D15229@cichlids.cichlids.com> <20000607134522.A353@FreeBSD.org> <20000607205859.A16247@cichlids.cichlids.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 07, 2000 at 08:58:59PM +0200, Alexander Langer wrote:
> Not at the moment.
> But I believe I'm talking against a wall or something:
>
> **********************************************************************
> * THERE IS ALREADY THE POSSIBILITY OF HAVING A SEPERATE ARCH/OPSYS *
> * PATCHDIR.
>
> [snip]
Ok. Deep breath.
1. I'm fully aware that bsd.port.mk provides the capability for
patches.<arch> directories.
2. I'm also fully aware that you're trying to extend this capability
into what you perceive to be a useful manner.
However, I believe that (1) is fundamentally flawed, since it
provides nothing that well-written patches, in a single directory,
cannot also do.
So far, we have discussed two types of patches, which can be handled
by either #ifdef's, or uname -m. If (and I have yet to see any
evidence that this is true) we ever come across something that
cannot be handled in this manner then:
(a) We either whack the software, or FreeBSD, into shape, to allow
simple "what architecture am I?" decisions to work
(b) we fall back to the EXTRA_PATCHES, surrounded by .if constructs
in the port Makefile
(c) I'll send you some virtual beers, or should we ever meet
in person, the drinks will be on me.
Thus, in the general case, patches.<arch> is not needed, and in the
special cases above (should there ever be any), there are other
options for workarounds.
Therefore, I'm suggesting that ALL support for patches.<arch>
be removed from bsd.port.mk -- by definition, that includes your
extensions.
To a certain extent we (FreeBSD porters) have had it pretty easy
up until around about now, only having to deal with one underlying
architecture. Certainly, for x86, there can be no question that
we have the most effective ports/packages tree currently available.
That needs to change, however, with the introduction of the Alpha
port, and a few more waiting in the wings (I'm already starting to
have nightmares about making GNOME work on them :) -- we have
to be very, very, careful about the choices we make on how to handle
multiple architectures, since once the ball is in motion, it's
going to be very messy to change it later on.
So far, the discussion has been somewhat polarized, but I think we
can work with what's been said so far, get a few more people
involved here (wake up, ye porters of the Seventh Seal!), and then
just get on with it.
It's obvious that David and I are in a similar frame of mind,
preferring a single directory, with patches (re)written in
an architecture-dependent manner. That's 2 votes.
We have your suggestion, which is to extend the present scheme as
provided by bsd.port.mk. That's 1 vote.
We have the status-quo option. No votes, yet.
Anyone else want to speak up? Will? Jim? Max? Satoshi?
> So if not, you're going to provide a patch that completely removes the
> possibilty of having different patch dirs?
That's the easy bit, which will take about a minute to do, should
we go for that option. However, in this case, the issue is deep
enough that it needs to be resolved before patches are made up.
-aDe
--
Ade Lovett, Austin, TX. ade@FreeBSD.org
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000607170352.F353>