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.43) id 1E9wli-0000oT-8P for garchives@archives.gentoo.org; Tue, 30 Aug 2005 03:26:38 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7U3OEvS008917; Tue, 30 Aug 2005 03:24:14 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7U3OD61027815 for <gentoo-osx@lists.gentoo.org>; Tue, 30 Aug 2005 03:24:14 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E9wlL-0001XJ-AL for gentoo-osx@lists.gentoo.org; Tue, 30 Aug 2005 03:26:15 +0000 Date: Mon, 29 Aug 2005 22:26:07 -0500 From: Brian Harring <ferringb@gentoo.org> To: gentoo-osx@lists.gentoo.org Subject: Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages. Message-ID: <20050830032607.GI13987@nightcrawler> References: <18866DB0-371C-4BB7-8C6D-94227F9B748A@gentoo.org> <4310DBE6.5040305@gentoo.org> <D3032A13-D352-43FB-851A-2FEB4986DA5C@gentoo.org> <4312BA20.4000504@gentoo.org> <Pine.LNX.4.63.0508291802040.31387@loopy.telegraphics.com.au> <2134124F-DB37-4FFC-9F76-C75BC62B0A7F@gentoo.org> <Pine.LNX.4.63.0508301201590.5950@loopy.telegraphics.com.au> Precedence: bulk List-Post: <mailto:gentoo-osx@lists.gentoo.org> List-Help: <mailto:gentoo-osx+help@gentoo.org> List-Unsubscribe: <mailto:gentoo-osx+unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-osx+subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-osx.gentoo.org> X-BeenThere: gentoo-osx@gentoo.org Reply-to: gentoo-osx@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Encpt1P6Mxii2VuT" Content-Disposition: inline In-Reply-To: <Pine.LNX.4.63.0508301201590.5950@loopy.telegraphics.com.au> User-Agent: Mutt/1.5.8i X-Archives-Salt: d72f78a4-18a0-4dab-b670-3c70fd8e938e X-Archives-Hash: a7d1ebe0e3905c994ba701d67db5e001 --Encpt1P6Mxii2VuT Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sidenote, no need to cc, just joined the ml for the discussion in the=20 meantime since people occasionally forget to cc (I know I do). On Tue, Aug 30, 2005 at 01:09:49PM +1000, Finn Thain wrote: > > I'm not sure I agree. I think this gets too close to a package.provided= =20 > > situation, portage will never know enough about another systems package= s=20 > > to map their functionality to its own. I think its preferable to let=20 > > portage handle what it knows first hand before trying to force it data= =20 > > from a foreign host. >=20 > I'm not proposing that one "injects" non-identical packages under the sam= e=20 > names. Actually, I have been against that since the beginning. >=20 > I was thinking of something like, at run time, query the vendor package= =20 > manager and use the result to populate the tree with packages like=20 > vendor-apple/sys-devel/xcode-1.5, vendor-sun/app-arch/cpio-x.y.z for=20 > example (please substitute sgi, bsd-ports, redhat or debian etc if you ar= e=20 > hostile to any of my examples). >=20 > Apple's XCode is closed source, and sun's cpio is now open. The former=20 > requires an ebuild to invoke installer(8), the latter requires an ebuild= =20 > to build it from source. No-one is lying to portage here. >=20 > And, if sys-apps/bsd-awk-x.y.z builds the same thing that apple ships, it= =20 > can provide vendor-apple/sys-apps/bsd-awk. >=20 > Also, the ebuilds for both vendor-apple/sys-apps/bsd-awk and=20 > sys-apps/bsd-awk should provide virtual/awk. So, when arbitrary ebuild fo= o=20 > wants generic awk (doesn't care about gnu extensions), it can depend on= =20 > that virtual (unless virtuals are to be deprecated, in which case foo=20 > somehow has to depend on any vendor, including gentoo). The rewrite's domain's abstraction (additionally the goal of binding=20 the resolver to the domain, and being able to do inter-domain=20 resolving) would allow for this, but I *really* don't think it'll work=20 well. Reasoning is, how do you know that pkg xyz is actually the package=20 you're after? The expanded restrictions subsystem, specifically=20 ability to depends based on contents restrictions (I want the pkg that=20 owns file abc essentially) gives basic ability for this, but it=20 doesn't cover the abi angle. What you're proposing could sort of be hacked together to pull off=20 strictly for src compiles, probably with a good collection of=20 impossible to quash annoying bugs. Doing it for binaries is a helluva=20 lot harder though. :) > > >IMHO, this sounds like a "gentoo-darwin" sub-project to gentoo-alt,=20 > > >along-side os x and bsd. It isn't really a fork except in as much as= =20 > > >the profile arrangement doesn't really accomodate work on darwin prope= r=20 > > >(but then the profile arrangemnet is flawed anyway: it only exists thi= s=20 > > >way because of the package.provided crutch). > >=20 > > I was looking at it more as a place to develop some new portage=20 > > features...Gentoo/Darwin has always been lurking, this is more in the= =20 > > area of just getting offsets working. >=20 > OK, I see what you are getting at now. That was something that I failed t= o=20 > infer from the email you forwarded to the list. Most of what I said in=20 > reply isn't very relevant to that. Excepting that, if you can leverage=20 > existing packages, prefixed installs are much more useful -- having a=20 > complete set of deps installed on a prefix is not much better than a=20 > stage3 chroot with your home directory bind mounted below it. The rewrite's general core is intended to allow for alt=20 formats/repos/whatever jammed into it; that said, making seperate=20 formats play nice with each other (unless they can natively) isn't=20 something I think is incredibly easy to pull off, as mentioned above. Thoughts? ~harring --Encpt1P6Mxii2VuT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDE9HOvdBxRoA3VU0RAuSHAJ9zSDjEg9bdylfM6OIAxfMfB8CeOACgsFUt ROYMwDtIkkURRMBfUqXQLrY= =/cAU -----END PGP SIGNATURE----- --Encpt1P6Mxii2VuT-- -- gentoo-osx@gentoo.org mailing list