From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Fgk1d-0005M1-5G for garchives@archives.gentoo.org; Thu, 18 May 2006 15:02:53 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4IF0kXR021512; Thu, 18 May 2006 15:00:46 GMT Received: from callisto.cs.kun.nl (callisto.cs.kun.nl [131.174.33.75]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4IEsxig016745 for ; Thu, 18 May 2006 14:54:59 GMT Received: from localhost (localhost [127.0.0.1]) by callisto.cs.kun.nl (Postfix) with ESMTP id E60F76F0014 for ; Thu, 18 May 2006 16:54:59 +0200 (CEST) From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Date: Thu, 18 May 2006 16:54:58 +0200 User-Agent: KMail/1.9.1 References: <20060516161549.442b4d8a@localhost> <20060517205347.GE8220@superlupo.rechner> <20060517213445.GA10063@netswarm.net> In-Reply-To: <20060517213445.GA10063@netswarm.net> X-Face: #Lb+'V@sGJ;ptgo5}V"W+5OCoo{LZv;bh,s,`WKLi/J)ed1_$0;6X<=?utf-8?q?700LVV/=3BLqPhiDP=5E=0A=09=27f=5Dfnv?=@%6M8\'HR1t=aFx;ePfp{ZQoBe+e)JOQ8T5*(_;mHY+cltLGq<;@$Y,=?utf-8?q?O=5C=24=0A=09Tm=23G6M?=,g![Q62J{na*S9d;R[^8pc%u\aiLqU@`kJtYl"^6pxdW Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1554741.mFVKaJxk5e"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605181654.59265.pauldv@gentoo.org> X-Archives-Salt: d16d132e-2615-4990-b56f-9fe697571602 X-Archives-Hash: 118a41a73068b2c42be8cb083dcebb19 --nextPart1554741.mFVKaJxk5e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 17 May 2006 23:34, Christian Birchinger wrote: > I think at the moment there's no plan to replace anything. > There was a simple request to add a profile to make it easier > for some people to develop something. We can talk about > replacing anything later, when there are more intrusive > requests like changing all ebuilds etc. What is then the purpose of paludis. Is its purpose to create a package=20 manager for a new distro, and the paludis team would like to use gentoo=20 as a testing ground? Or is the purpose of the paludis team to have paludis be an alternative to= =20 portage. In that case it should respect portage, and make efforts to=20 follow the standard that portage sets. > > I honestly think people are just bringing up the wildest things > just to find another reason to say "no". It Looks a bit like > even good ideas and project have no chance when they come from > "the wrong people". If I only wanted to say No, I would not have needed this many words. Many=20 of what I said applies just as well for pkgcore as for paludis (or any=20 other package manager).=20 What I have done is stated: =2D Why paludis accomodations are too early at this moment =2D Why package managers should not have their own profiles =2D What categories of package managers can exist (candidate replacement, secondary, third-party) =2D That there can only one primary package manager =2D What requirements exist for a secondary package manager =2D What requirements exist for a candidate replacement package manager =2D How paludis developers could enhance paludis such that it could be considered as a candidate portage replacement. =2D That the decision to replace portage should be made explicitly and should not be forced upon the project by packages in the tree requiring the candidate replacement package manager =2D That accomodations for a package manager can only be made for candidate package manager or for a secondary package manager (that must encertain full portage compatibility). Let's give some examples of what candidate package managers and secondary=20 package managers can do. One of the biggest issues for amd64 is the fact that packages can not be=20 installed for particular architectures or in paralel. An alternative=20 package manager could offer a way that while allowing each architecture=20 to be installed separately, it merges the files into one package and=20 maintains separate files that record which subpackage which file belongs=20 to. This way portage can remove the package, see that it's there and even=20 verify the contents. It only can not itself provide multi architecture=20 installation. Another thing is reverse dependencies. This is missing from portage, but a= =20 feature that could well be implemented independent of the on-disk system. Aditional package formats could be supported. The only restriction is that= =20 these must not be used in the official tree. They can be used in=20 overlays, or in case of rpm support just used to install rpm packages and=20 achieve a bigger LSB support. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart1554741.mFVKaJxk5e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3-ecc0.1.6 (GNU/Linux) iD8DBQBEbIrDbKx5DBjWFdsRAlyrAJ938m+lSqi1vL4taTTHfOu6XcXdaQCbBgeY Sb16IdqaZ7aARCxcl0wlXgs= =2XiZ -----END PGP SIGNATURE----- --nextPart1554741.mFVKaJxk5e-- -- gentoo-dev@gentoo.org mailing list