From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21849 invoked from network); 21 May 2004 22:41:10 +0000 Received: from smtp.gentoo.org (156.56.111.197) by parrot.ussg.indiana.edu with SMTP; 21 May 2004 22:41:10 +0000 Received: from parrot.ussg.indiana.edu ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BRIhR-0006xC-E7 for arch-gentoo-dev@lists.gentoo.org; Fri, 21 May 2004 22:41:09 +0000 Received: (qmail 21864 invoked by uid 89); 21 May 2004 22:41:08 +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 15546 invoked from network); 21 May 2004 22:41:08 +0000 Message-ID: <33709.68.78.66.41.1085179258.squirrel@webmail.neoturbine.net> In-Reply-To: <1085178508.8753.156.camel@newkid.milsson.nu> References: <200405201846.37173.cbrewer@stealthaccess.net> <40AD80D1.6050504@skylineaero.com> <20040521063324.GC8475@curie-int.orbis-terrarum.net> <1085145580.8753.93.camel@newkid.milsson.nu> <1085146797.25036.52.camel@localhost> <1085158789.8753.112.camel@newkid.milsson.nu> <1085165137.25036.92.camel@localhost> <1085178508.8753.156.camel@newkid.milsson.nu> Date: Fri, 21 May 2004 17:40:58 -0500 (CDT) From: "Joseph Booker" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: Re: [gentoo-dev] Stuff that makes people mad X-Archives-Salt: 2d1d0da8-b356-48f3-882f-7ed5cad51e82 X-Archives-Hash: 721ff3e9410a253c9f399d3bdff29764 John Nilsson said: > On Fri, 2004-05-21 at 20:45, Chris Gianelloni wrote: >> On Fri, 2004-05-21 at 12:59, John Nilsson wrote: >> > When I emphasized "NEED" I didn't mean the official requirement I >> menat >> > the practical/technical requirement. >> > >> > I meant: Can we engineer a solution to the problem removing the need >> for >> > maintainers but still meeting the requirements? >> >> No. One of the requirements is that someone is responsible for that >> piece of software and what it does on YOUR system. Would you prefer w= e >> just arbitrarily assign out responsibility for packages? I vote that >> YOU get to take over OpenOffice, KDE, Gnome, GCC, and glibc. I'll tak= e >> bash. ;] > > I'm just talking about ebuilds, not the entire software world! =3D) If = we > can remove the need for ebuilds no one has to maintain them. The proble= m > I see is that the work spent on maintaining ebuilds (installation > scripts for one linux distribution) could be spent on the actual > software instead, benefiting all systems. > >> > I view an ebuild as a kind of hack at the moment. Ebuilds solve the >> > problem that open source software packages does not meet the >> > requirements of their users (distributors). >> >> Actually, LFS has proven that the software packages are pretty much OK >> amongst themselves, it is when you start bringing in numerous variable= s >> of versions, revisions, configure options, etc. that you start to get >> into the complexity that ebuilds try to relieve. Nobody is forcing yo= u >> to use emerge. Remember that. > > Ebuild solve a very real problem. That is why I use them. I'm just > asking if it is the best solution. > > >> > Ebuilds provide a uniform interface for configuring and installing. >> > Fair, does that need one maintainer per package? >> >> Yes. Though I know that personally, I probably maintain 20-30 >> packages. As a member of the 2 herds I am in (games/livecd), I would >> venture that number is closer to 200-300. Did I mention that there's >> only 4 of us (3 active) in games? The livecd herd at this time is jus= t >> me. > > But doesn't autoconf provide the same thing? > >> > Ebuild provide metadata for dependencies. Is this really the >> > responsibility of Gentoo or even Portage? I say, move that to the >> source >> > packager. >> >> I wouldn't mind seeing this done upstream. I'm not sure how it would = be >> done, but it would definitely make all of our lives much easier. > > I can think of many ways, ebuilds being one of them. The question is > rather why. Someone has to maintain the information. > >> > Ebuilds provide an "install shield" so that installed files can be >> > tracked, protected, removed, updated. Would it be correct to patch >> this >> > functionality into install(1) instead? >> >> ...or RPM, or apt, or yum, or pkgtools, or... > > again a job for ./configure > >> As you see, there are many competing packaging systems. What you >> propose would require everyone to agree on one. If you've learned >> anything about Linux, it is that everyone is out to build a better >> mousetrap. > > Any form of interoperability would do. > >> > Ebuilds makes sure that files go to the right places. A broken insta= ll >> > system is a broken install system. Patch automake/autoconf their >> purpose >> > is to make portability a breeze, why do we have another in house lay= er >> > on top? >> >> Pretty much read above. >> >> What you propose really is for Linux to unify. There would be no need >> for Gentoo, or Debian, or Red Hat. It would all just be Linux. It >> would all work the same and it would all feel the same. > > No what I propose is that move as much of the ebuilding as possible to > the package developers (in a portable way). And provide system agnostic > tools for the rest. > There would still be a need to patch and fork packages to suit Gentoo. > Generally make things stable and consistent. I'm only talking about > relieving some of the portage work from Gentoo developers and push it > upstream where all systems could benefit from it. > >> Well, sir. I wish you luck in the endeavour. Until then, I'll be her= e >> working on ebuilds and trying to make what we have today better. > > I hope you do. I'll try to do my bit to. =3D) ok, i totally get it: You would like every single package to conform to gentoo's way of packaging them so they dont have to be changed when emerged. This include= s kde installing itself by default in /usr/kde/ on all distros and all enviromental variables in /etc/env.d/ and for everything to use ./configure scripts (think of the -bin's!!!), for all the kernels to support koutput, for all the binarys to install by default to /opt............ This is a distrobution, you seem to want to get rid of that and go with a= n LFS-like solution those ./configure scripts are uniform thoughout the unix world for one reason: its good coding that does its job if you can code some system that works with packages as well as autoconf or make does, then try doing that before asking gentoo devs to push such an inititive --=20 Joe Booker -- gentoo-dev@gentoo.org mailing list