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 1FgnD2-0002GI-Dw for garchives@archives.gentoo.org; Thu, 18 May 2006 18:26: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 k4IINRl6027399; Thu, 18 May 2006 18:23:27 GMT Received: from psmtp01.wxs.nl (psmtp01-real.wxs.nl [195.121.247.14]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4IIIJLY017817 for ; Thu, 18 May 2006 18:18:19 GMT Received: from hex.local.devrieze.net (ip5457f303.direct-adsl.nl [84.87.243.3]) by psmtp01.wxs.nl (8.12.10/8.12.10) with ESMTP id k4IIIJni022371 for ; Thu, 18 May 2006 20:18:19 +0200 From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Date: Thu, 18 May 2006 20:18:24 +0200 User-Agent: KMail/1.9.1 References: <20060516161549.442b4d8a@localhost> <200605181654.59265.pauldv@gentoo.org> <20060518171135.62fa8fac@snowdrop.home> In-Reply-To: <20060518171135.62fa8fac@snowdrop.home> 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="nextPart4389859.Jd5PEom2xZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605182018.24694.pauldv@gentoo.org> X-Archives-Salt: d3be9ac5-814b-4faf-85cd-f9139ac72ae0 X-Archives-Hash: 1c9eb0c9389c818028c3392e333e5353 --nextPart4389859.Jd5PEom2xZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 May 2006 18:11, Ciaran McCreesh wrote: > On Thu, 18 May 2006 16:54:58 +0200 Paul de Vrieze > > wrote: > | What is then the purpose of paludis. Is its purpose to create a > | package manager for a new distro, and the paludis team would like to > | use gentoo as a testing ground? > | > | Or is the purpose of the paludis team to have paludis be an > | alternative to portage. In that case it should respect portage, and > | make efforts to follow the standard that portage sets. > > No single purpose. Approximate goals are usually as follows: > > * The QA tool part, which has already found a whole load of issues in > the tree and has had them fixed. No problem with that. > * An alternative to Portage. > > Paludis itself is distribution agnostic. It can be used on a Gentoo > system or on a non-Gentoo system as the user prefers. This would make it a third party packaging solution that happens to work to= =20 some extend with ebuilds. This would give paludis the big flexibility, not= =20 supported by gentoo option. This means that no paludis specific changes mus= t=20 be made to the tree. > > Paludis does not attempt to emulate every last oddity of Portage. It > does not attempt to be usable in parallel with Portage, since that > would prevent any useful features from being added. It *does* attempt > to work with all existing ebuilds. It *can* read Portage-generated VDB, > although at this stage we're strongly encouraging people not to try > that, because there will probably be a few bugs... That makes it not suitable to be used in replacement primary packager or=20 secondary packager roles. Leaving the third party role. Gentoo support woul= d=20 thus send the wrong signal. > | What I have done is stated: > | - Why paludis accomodations are too early at this moment > > By the same argument, icc shouldn't be in the tree. Even if that is true, icc has been in the tree since (12 Apr 2002) making i= t a=20 historical mistake that should be avoided for the future. > > | - Why package managers should not have their own profiles > > Yes, very nice in theory. Unfortunately, Portage requires a whole load > of Portage stuff in its profile, so that's not an option. Then submit patches to portage to make it profile agnostic. > | - What categories of package managers can exist (candidate > | replacement, secondary, third-party) > > This categorisation is a false trichotomy. There is no reason for it to > exist, and it has no value. Why and why? > > | - That there can only one primary package manager > | - What requirements exist for a secondary package manager > | - What requirements exist for a candidate replacement package manager > > Again, nonsense based upon some random arbitrary segregation you're > attempting to make that has no real world relevance. Baseless accusations that are not supported by any argumentation. As long a= s=20 you don't provide arguments I'll assume that you are out of arguments and t= ry=20 to convince me by baffling me. > > | One of the biggest issues for amd64 is the fact that packages can not > | be installed for particular architectures or in paralel. An > | alternative package manager could offer a way that while allowing > | each architecture to be installed separately, it merges the files > | into one package and maintains separate files that record which > | subpackage which file belongs to. This way portage can remove the > | package, see that it's there and even verify the contents. It only > | can not itself provide multi architecture installation. > > Can't be done without huge ebuild changes. And were we to do that, we'd > just implement multi-abi properly. Which would be trivial with Paludis > and impossible with Portage. I can easilly come up with a way to do it without portage changes. It cause= s=20 some stuff to be compiled too often, but does not break things. I can even= =20 invent some way that it does not "conflict" with portage VDB's. Why don't y= ou=20 use your intelligence to find ways to do things that do not conflict with=20 portage (or people). > > | Another thing is reverse dependencies. This is missing from portage, > | but a feature that could well be implemented independent of the > | on-disk system. > > Yes, carry on looking at the small picture. It's really really > interesting! These are just examples. Another example of a secondary package manager wou= ld=20 be one that would allow installation of rpm packages in a portage compatibl= e=20 way. I'm not hurt by you calling me names. It just shows that the accusatio= ns=20 against you were right. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart4389859.Jd5PEom2xZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux) iD8DBQBEbLpwbKx5DBjWFdsRAlfuAKC5VjtDOtHOyUw98dBuedqg/nn/FQCg0NKJ 5hQ1TiPKhfWFyXLPIc34NiM= =UuPK -----END PGP SIGNATURE----- --nextPart4389859.Jd5PEom2xZ-- -- gentoo-dev@gentoo.org mailing list