Didn't something special get implemented for libtool on the linux side? i.e. Isn't there about a ten different versions of it, and they're all installed, and there's a way for ebuilds to call the one they want? Could this be applied in a more general manner, or is this an ugly hack?
On Thu, 3 Feb 2005 01:08:12 +1100 (EST), Finn Thain <[EMAIL PROTECTED]> wrote: > > > On Tue, 1 Feb 2005, Hasan Khalil wrote: > > > ... > > > > We do not yet have policy for packages that are provided by Apple and that > > have a different API than that of the gnu version. I'm opening up the floor > > here for discussion on this. > > Well, first, write the ebuild for the BSD version :-) > > > What comes immediately to mind is making the said packages a virtual, and > > then satisfying the virtual in our profile. > > Yes. You just use the BSD one for a macos profile, and the GNU one for a > linux profile. > > I'm not completely serious about writing ebuilds for all of Apple's stuff > we depend on. I wrote to this list with a rant about "vendor" packages a > while back, to address exactly this problem. But, since OpenSolaris is out > now, it seems a bit irrelevant. > > This is probably just a naming convention issue, i.e. what do you call > Apple's cpio, Sun's cpio, etc in order to add them to package.provided and > thus satisfy the virtual. > > It gets interesting because, someday, someone will write an ebuild for > Darwin's cpio, and it will be the same as the OS X one. So, one might ask, > what are they going to call their ebuild & category, and I'll just put > that in package.provided. > > > This should work most of the time, as most packages that use, for > > example, zip, do not use any of the arguments that differ between the > > gnu and BSD versions. > > Yep, in those cases, you change the dep to be the virtual, and save some > time and space by using the already present (Apple) one. > > The problem arises when a package really needs the GNU version -- you > can't just specify that as a dep, since the GNU one will clobber the Apple > one, and people will get terribly upset. Or will it? Doesn't pathspec > permit both versions to be installed? > > -f > > -- > [email protected] mailing list > > -- [email protected] mailing list
