From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17363 invoked by uid 1002); 10 Jun 2003 00:01:26 -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 26671 invoked from network); 10 Jun 2003 00:01:22 -0000 From: "leon j. breedt" To: gentoo-dev@gentoo.org In-Reply-To: <20030604085215.GN10084@galen> References: <20030603220739.GB30852@inventor.gentoo.org> <20030604085215.GN10084@galen> Content-Type: text/plain Message-Id: <1055203280.2168.24.camel@ash> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 10 Jun 2003 12:01:20 +1200 Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Portage Ported to OS X X-Archives-Salt: 7e0cc516-8d9e-4472-880c-ab14e3ccb5ab X-Archives-Hash: 583501ffbb20779f587d367ee8fa1e7f On Wed, 2003-06-04 at 20:52, Joseph Carter 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: advantages of DebianStyle(R)(TM)(C): - extensive set of tools to validate and QA packages (lintian is really full-featured) - 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. 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 - 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... - 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? - 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') disadvantages of ebuilds i've noticed: - one ebuild can't generate multiple installed packages. this is why i suppose eclasses were invented. 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. i still use both Debian and Gentoo :) leon -- gentoo-dev@gentoo.org mailing list