Re: [gentoo-dev] Portage Ported to OS X

[Joseph Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jun 10, 2003 at 12:01:20PM +1200, leon j. breedt wrote:
> > Any plans to cooperate with the fink people on this?  That might be
> > getting a bit out of the realm of what's normal and expected for Gentoo,
> > but I happen to think that portage is a lot better suited to building fink
> > packages than anything Debian's got these days.
> ah, i cannot resist responding to that jab from a developer's
> perspective:

You are talking to a Debian developer, if one who has been inactive for
the last eight months or so and has kinda replaced all his Debian machines
with Gentoo in the time since..  ;)


> advantages of DebianStyle(R)(TM)(C):
> - extensive set of tools to validate and QA packages (lintian is really
> full-featured)

linda is looking very promising too.  linda is a python replacement for
lintian which is deemed easier to maintain, but not quite as full featured
yet.


> - picky policy on where things should go, what should always be in a
> package, etc. and its documented, whereas some things are still kind of
> up in the air for Gentoo, or more just guidelines...gives a consistent
> feel to Debian.

The Debian policy has very little to do with the mechanics of packaging.
It is purely a set of guidelines for how the packages should behave once
they get installed.  Gentoo could adopt Debian's existing policy wholesale
today and make all ebuilds conformant.  Note, I do not advise this - it
would be better to carefully evaluate each portion of the policy and
decide what should be kept and what should not be.  Some of the details
are things Gentoo likely does not agree with.


> disadvantages of DebianStyle(R)(TM)(C):
> - takes too long to get your head around the complete building process,
> there are lots of docs and policy to take in, in more than one set of
> documentation

There are no less than six different build systems involved with Debian:
debmake (which refuses to die), debhelper, hand-rolled makefiles, multiple
versions of Doogie's Build System, and an assortment of minor things used
by a smaller group of people - including systems which try to emulate the
.spec format of RPM and Gentoo's own ebuilds.

All of thse build systems are maddeningly complex.  Mostly this has to do
with the complexity of splitting packages up into smaller pieces,
providing complex yet generic and limited configuration interfaces via
debconf, the differences between source and binary dependencies, etc.
Since Gentoo begins with source and always installs the documentation and
development tools with a package, nearly all of Debian's complexity is
gone, instantly.

There's also something to be said for a script and a bunch of extra files
for a source package system.  Beats a tarball and a diff anyday!


> - too many ways to set up the build process...the policy just dictates
> some expected files and expected debian/rules targets, so you're free to
> do it in your own way, which leads to wheel reinvention.
> - ad-hoc external patch (changes outside of Debian-specific diffs)
> mechanisms (dpatch, dbs, hand-rolled). dpatch requires you to create a
> damn script for each external patch you want to apply (argh!!). there is
> a tool to help with this, but still...

As noted above, yes.


> - too much legacy stuff hanging around (probably understandable, given
> ~8000 packages), so improvements to the package build system as a whole
> are in tiny tiny increments: they're too scared of breaking backwards
> compatibility for new features. NB: how is Gentoo going to handle
> scaling while maintaining Portage feature increase?

You have gone way off the topic of fink.  I noted only that Gentoo's build
system makes much more sense for building UNIX tools for a Mac than the
huge mess of things Debian uses.

fink does not have 8000 packages.  By the way, at last count, in December,
Debian had 11000 packages in unstable.  These packages must become stable
on a dozen different architectures at once and not have any significant
bugs which would make you not want to release them.  Is it any wonder that
Debian's last release was nearly a year ago and they're nowhere near ready
to produce another?  At the rate Debian grows, release complexity grows
exponentially.  This is not a good thing for Debian's users.


> - sucky kernel module building system (tried building nvidia-kernel on
> Debian? heh...due to it using make-kpkg, less than intuitive compared to
> 'emerge nvidia-kernel')

kernel-package is a very nifty tool (if complex and scary even by perl
standards..)  The problem is that people do not implement the modules
correctly.  This is noteworthy since supposedly using fakeroot you can
build your kernel without root priveleges in your home directory.  Yet
modules such as nvidia-kernel insist on /usr/src/linux.  What's up with
that?  They're bugs, naturally.  But if the maintainer does not want to
fix the bugs, they don't get fixed as a rule.  Sure there are NMUs, but
there is so much process and policy associated with them that bugs tend to
go unfixed.

If a package, say bash for example, has a bug in Gentoo, it gets fixed
either by the person who normally works on bash, or by the person who
decides the bug is annoying enough to fix.  In Debian, you may not fix the
bug no matter how annoying it is without consulting with bash's maintainer
unless you've tried and gotten no answer for a substantial period of time.
People who fix bugs after waiting weeks for a reply still get flamed for
not waiting long enough before trying to fix the bug.  Other times they
find that the maintainer didn't respond because he didn't consider the
thing a bug or whatever else..  These kinds of things just don't happen in
Gentoo because that's not the way this project operates.  Bugs are things
which need to be fixed, period.  If something is deemed not a bug by the
person who normally takes care of a package, there's a discussion (read;
flamewar) and some conclusion is eventually reached.  Never in Gentoo have
I seen someone get flamed for fixing what everyone agreed was a bug,
though.


> disadvantages of ebuilds i've noticed:
> - one ebuild can't generate multiple installed packages. this is why i
> suppose eclasses were invented.

I consider this a feature, to some extent.  Multiple packages really make
things more complex.  It's easy to want to be minimalist and not install
extra docs or headers with a library, but having to install all of these
things seperately is really user-unfriendly.


> by no means a definitive list, but for those of you that aren't from a
> Debian maintainer background, some things i ran into during my tenure.
>
> Gentoo isn't doing all that badly, though. Debian was pretty ad-hoc in
> the early days, so i'm positive for Gentoo's future.

The way I look at it, with 11,000 packages and a dozen archs, Debian's
release prospects are sadly not very good these days.  The endless
politicking and policymaking are stifling, and the barrier to entry
continues to grow while many of the more intelligent and level-headed
developers (I will not even _pretend_ I am among the level-headed group)
have been leaving the project for years because they just can't deal with
it all anymore.

Hamm was a pretty solid release.  Slink was solid too, but it had some
problems that should have been fixed.  Potato was forever and a day in
coming, and moved Debian finally into the realm where 2.2 kernels were
officially supported, long after everyone else had migrated to 2.2 just so
that their distributions would boot on modern hardware.  An attempt to
update Slink to 2.2 was made, but rejected by Debian even though the work
had already been done - it was not necessary, they said, because potato
would be out "soon".  It was more than six months before potato was
actually released.

And potato too languished, lacking support for 2.4 kernels.  For more than
two years, it languished while Debian tried to stabilise woody.  Woody
shipped with a 2.2 kernel, but with the option for 2.4.18.  Note, the
2.4.18 kernel did not have the IDE patch necessary to operate on ATA133
controllers which had already been incorporated into 2.4.19pre1 before
woody was released.  Consiquently, I reported this a month before woody
was released, and nearly a year later Debian does not have a way to boot
woody on my ATA133 system.  If I wanted to install Debian on my system, I
would follow a procedure very similar to the one I use to install Gentoo.
In fact, I've had to do so twice.

And besides, if Hamm was solid, Slink was a little less so.  Potato was
forever in coming, and had a couple of problems when it finally did
arrive.  Woody had a number of problems when it was released.  Oh sure it
still beats the crap one must put up with if they use RedHat or Mandrake,
but Debian just isn't quite as good as it was when I got started with it,
about six months before Hamm was released.


Gentoo, on the other hand, has improved remarkably over the past year.  It
has gone from being less reliable than the average RPM distributions to
being just as reliable as Debian, maybe moreso if you consider Debian
unstable.  It lacks the easy configuration, and it is a pain in the ass to
compile everything all the time, but you know what?  If compiling
everything means that the quality of the system will not degrade as has
been happening with Debian, it's worth it.  The rest of Gentoo's problems
are small and will be fixed sooner or later.  If history is an indication
of the future, it will be sooner.


> i still use both Debian and Gentoo :)

I do not, at this time, have a place for Debian on my network.  There are
tasks to which Debian is ideally suited, even if it is no longer as good
as it used to be, but I'm not currently doing any of those things.

Right now the only task I have which is not handled best by Gentoo cannot
be done any better by any Linux.  The correct combination of hardware and
software for the task seems to be an iBook or Powerbook 12 with MacOS X
and some other Apple software, combined with a small collection of tools
ported from UNIX and Linux.  For the moment, that means fink, which is how
we got into this discussion in the first place.

- -- 
Joseph Carter <knghtbrd@××××××××××.net>      Available in cherry and grape
 
* Simunye is on a oc3->oc12
<daem0n> simmy: bite me. :)
<Simunye> daemon: okay :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: 1024D/20F62261F1857A3E79FC44F98FF7D7A3DCF9DAB3

iEYEARECAAYFAj7l03AACgkQj/fXo9z52rMj+QCgonUQY216NY6+QWqiCGlevGsZ
D3YAoKibUcPEMepuX9AmOGPzmRvWvRzK
=ARLc
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list