On Fri, Dec 05, 2003 at 01:28:03PM +0100, Robert Millan wrote: > On Thu, Dec 04, 2003 at 06:46:05PM -0700, Joel Baker wrote: > > > > > > Untill we resolve this, please take into consideration to avoid filing > > > patches > > > that use "netbsd-i386" in a way that breaks the other port. I've been > > > careful > > > to keep such incompatible patches without submitting, since I started. > > > > A bit late for that, I'm afraid; they're already fairly pervasive, > > particularly throughout the toolchain. > > I know that. But I'm not asking you to revert the existing incompatible > changes, I understand it wouldn't make sense to do that. I just ask to not > add more of them. > > > Except in the case of things like libc. Which tend to pop up more than one > > might imagine. Unfortunately, it's also true that quite a few maintainers > > already have ARCH logic, and are not entirely amenable to just randomly up > > and changing this because we can't figure out what we want to do. > > You can handle libc dependencies portably I think, instead of: > > libc12-dev [netbsd-i386] | libc1-dev [freebsd-i386] > > Just do: > > libc6-dev | libc-dev
Which works great, if it's libc-dev that's needed. It fails fairly
severely, if a specific version of a library is needed due to, say, a fix
in an included library that also requires a fix in the application.
Not to mention packages like GCC, which use m4 substitution based on ARCH
to decide whether to put in a libc12-dev or a libc-6dev, for fairly good
reasons. Of course, as I said before, *most* of those changes are already
in place anyway.
I don't think I've ever filed a patch using arch-specific stuff for
netbsd-i386 in the Depends or Build-Depends that did not involve something
that would have (msot likely) been different between the two. Changing
the libc is such a fundamental thing that it cascades throughout the port
rapidly, in any place that it matters in the first place.
Which presents a fairly difficult situation. While I'm happy to use system
type, when that is, in fact, the applicable switch (and, stipulated, it may
well be applicable in some places where ARCH has been used to date), its'
going to be fairly difficult to argue that either port is 'useable' when
the patches aren't integrated at all. (Plus, frequently, maintainers have
asked for changes to the patches, before accepting them; thus, what lives
in a CVS area, which is what I did while starting, may often not resemble
the final results).
Which is all a long way of saying that I don't see an easy solution, and
that people are probably right in being frustrated by the entire lack of
coherence of the 'Debian BSD port' effort. I don't think we even have
enough people to take a meaningful straw poll (though I could be mistaken,
of course).
--
Joel Baker <[EMAIL PROTECTED]> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
pgpFsmt9VTGXg.pgp
Description: PGP signature
