From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2545 invoked by uid 1002); 10 Jun 2003 12:47:18 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 32075 invoked from network); 10 Jun 2003 12:47:17 -0000 Date: Tue, 10 Jun 2003 05:47:44 -0700 From: Joseph Carter To: "leon j. breedt" Cc: gentoo-dev@gentoo.org Message-ID: <20030610124744.GD31721@galen> References: <20030603220739.GB30852@inventor.gentoo.org> <20030604085215.GN10084@galen> <1055203280.2168.24.camel@ash> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <1055203280.2168.24.camel@ash> X-Operating-System: Linux galen 2.4.20-gentoo-r2 X-No-Junk-Mail: Spam will solicit a hostile reaction, at the very least. User-Agent: Mutt/1.5.4i Subject: Re: [gentoo-dev] Portage Ported to OS X X-Archives-Salt: 0fea664e-54a3-47a7-bbf2-32f7b857742a X-Archives-Hash: f583c58c223b3ea5208635744254bbd6 -----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 Available in cherry and grape * Simunye is on a oc3->oc12 simmy: bite me. :) 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@gentoo.org mailing list