[buug] cockroaches and kernel build

Nick Moffitt nick at zork.net
Fri Aug 9 14:14:28 PDT 2002


A little mixed quotation, for context:

begin  Rick Moen Lives Three Hours from Nowhere  quotation:
> I see that Nick beat me to it.  And he's the perfect person to
> address other parts of this topic (a point I'll return to later),
[...later...]
> Completely source-oriented Linux distributions include Gentoo,
> Source Mage, and Lunar Linux.  Nick Moffitt's newly developed GAR
> framework, now being extensively used in the LNX-BBC project, is
> shaping up into the foundation of a full-blown source-oriented Linux
> distribution, and should look familiar to those who've studied the
> BSD ports system -- but much cleaner.
[...and earlier again...]
> Since the conversation has lamentably turned serious, I should
> stress that what makes Debian work isn't really apt-get, but rather
> the application of Debian Policy.  Since I've had this conversation
> before, please pardon the FAQ reference:
> http://linuxmafia.com/~rick/linux-info/debian-policy

	And this has of course been the crux of all our problems with
GAR, too.  Look at gar.mk and gar.lib.mk, and compare it to just
bsd.port.mk.  You'll see that it's a far more elegant and orthogonal
design, with much to recommend it.

	And yet, as a useful tree of software, GAR totally sucks
compared to BSD ports.  Why is that?

	Well, partly it's because BSD has had a long time to hammer
out port maintainership to a science.  They've managed to implement
the same kind of package standards (arguments about levels of quality
can be had on the bsd advocacy lists) as Debian's.  GAR is a young
tree that is still working on hammering out standards like these:

	* http://gar.lnx-bbc.org/wiki/RulesAfterInclude 
	* http://gar.lnx-bbc.org/wiki/ImplicitDestdirConsideredHarmful

	Now, to defend GAR, it's also trying to solve a number of more
difficult problems than BSD ports.  It's trying to build on a wide
variety of systems (did you know that I've gotten GARNOME bug reports
from HP-UX and AIX users?  We were only half-joking when we said that
the next batch would probably be from CygWin!).  As far as the BBC
goes, it's trying to build filesystem images without requiring root
privilege (which we succeeded in doing, I'm very happy to say!).

	We're also trying to build glibc, which is sysyphian to say
the least.  Because of this, we're currently somewhat bound to a
rather specific Debian installation (certain header files confuse
glibc's build to destruction).  It's a lot like trying to do the BSD
world plus ports on a system where EVERYTHING is a port.  It's messy.

	So I can categorically say that no matter how neat your
packaging tools are, they are simply that -- a tool for implementing
packaging policy.  All the real work goes into package polishing and
testing.  These tools remind us that packages do not exist in a
vacuum, and must behave properly in some rather bizarre constellations
of installed software.

> Because of that consistent, enforced content policy, it's literally
> true (not just an aspiration) that you need only install Debian on a
> host once, and never need install new versions:  New "releases" are
> just new starting points with improved starting hardware support,
> and have no relevance to already-running systems.  Instead of big
> version jumps (and downtime) at ~6 month intervals when new
> distribution "versions" come out, a Debian system's admin just
> resynchronises it occasionally to current versions of his installed
> packages on the Debian package mirrors, which receive package
> revisions (from the 1000+ package maintainers) on an ongoing basis.

	I upgrade my box daily.  Usually I'd say it averages a couple
of packages upgraded per day -- more on my desktop box.  BSD folks
find the same thing with their cvsup port rebuilds.  FreeBSD has a
nice script to automate upgrades of already-built ports.

-- 
Jack Valenti is to the American film viewer and the American public
as the Boston strangler is to the woman home alone. 
      -- http://cryptome.org/hrcw-hear.htm    (search for "Boston")



More information about the buug mailing list