I wanted to reply to this one earlier, but gave up after mozilla crashed on the half-finished mail ..
On Fri, 8 Aug 2003, Per [iso-8859-1] Øyvind Karlsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 08 August 2003 13:44, Joe Baker wrote: > > Two and a half years ago I was enchanted with Mandrake Linux. The > > release cycles were much faster and more bold at using the latest > > versions of the applications that people wanted at the time. She > > was feature rich and still leads the pack in the installation > > many categories. I'm always pleasantly delighted that I can design > > and implement such a complicated filesystem layout including > > elements of the Logical Volume Manager, Raid and my choice of all > > the big file systems that are out there today - Right from the > > installer menu! > > > > My point is this... I want Mandrake to offer Portage for access to the > > latest application compiling. > > I don't necessarily think it is necessary to hve portage itself, possibly a port to rpm/urpmi? > > Portage is being made available for Mac's OS X, and the Cygwin project > > on Windows. > > Mainly because they didn't really have package management tools equal to apt or urpmi or even rpm. > > Portage is one of the best development tools to come along under the > > GPL banner. Even BSD "Ports" fans are envious of Portage. > > Well, this probabaly isn't the best time to bring this up with all > > the intense debugging going on and the agressive deadlines that > > you're trying to make. But it is food for thought about the future. > > This integration would set Mandrake apart from all the other distros > > in an amazing way. > > > > Food for thought. > > > > Best Regards, > > > > Joe Baker > > President, Digital Communications Research, Inc. > This subjet has been discussed several times earlier, and we've always come to > the conclusion that it's really not worth it, it doesn't really provide any > real advantage in performance Forget about the performance aspects for a moment, since they are mostly irrelevant, but the package management aspects may be ... > and introduces alot of bugs, headaches etcetc.. > browse the archives and you'll find several threads on this.. > anyways, why being so obsessed by the *latest* from cvs, latest devel version > etcetc., Because in some cases: -you may be developing from CVS, why not have tools to help manage your software built from CVS -the software in CVS may be useable, just not feature-complete or the documentation may not be complete I build weekly snapshot RPMs for 9.1 of grass from CVS (grass51), and I have had over 28 downloads of some snapshots, indicating that people running a stable release may be interested in selected software that may not be released yet. In some cases, such software may be in cooker, but then you may have to endure instability in other software you only want to use. For instance, to have geotiff support in the stable release of gdal, you need a beta of libtiff-3.6. > cooker is usually quite up to date on most areas, But what about stable releases? Sure, it's normally trivial to rebuild something from cooker, and probably most people running cooker have a stable system they run some rebuilds from cooker on. So, would it not be useful to reduce the amount of time cookers spend rebuilding software from cooker on stable releases? > and you'd rather > want something that's tested and actually works, don't you? And who is going to test it if it's not packaged? Only the people who are prepared to build from source, and if more than (say) 4 people do this, we're wasting man-hours. Imagine if you could setup cooker as a "source" media in urpmi, and if a dependency is not met by your "stable" source, it installed all the buildrequires (of course, some setup with sudo for urpmi would be required), downloaded the SRPM and rebuilt it for you, and installed the resulting rpm? And say some buildrequires weren't satisfied, it could build them too. And say it had support for building with a spec file from Mandrake's CVS, then you could pick versions which no longer exist in cooker too. You could also have hdlists generated, and the location of the final RPMs referenced as a binary urpmi media for other machines of the same release. And what if you don't like the options that are default in a package? If standard macros were adopted (say _use_<feature>, for example _use_ldap), and packages where this distinction is useful were modified to use them correctly, it would be trivial to install packages with the features you want. If you forget about the "optimisation" arguments, and think about the time-saving and customisation aspects, I think a tool like Portage for rpm/urpmi would be useful. Just think, we may never see complaints about cooker packages not working on a stable release again! Regards, Buchan -- |----------------Registered Linux User #182071-----------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ****************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. ******************************************************************
