Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.

[Finn Thain]

On Tue, 30 Aug 2005, Brian Harring wrote:

> On Tue, Aug 30, 2005 at 09:33:36PM +1000, Finn Thain wrote:
> > On Mon, 29 Aug 2005, Brian Harring wrote:
> >
> <inserting the relevant quote>
> > > > I was thinking of something like, at run time, query the vendor
> > > > package manager and use the result to populate the tree with
> > > > packages like vendor-apple/sys-devel/xcode-1.5,
> > > > vendor-sun/app-arch/cpio-x.y.z for example (please substitute sgi,
> > > > bsd-ports, redhat or debian etc if you are hostile to any of my
> > > > examples).
> > >
> > > The rewrite's domain's abstraction (additionally the goal of binding
> > > the resolver to the domain, and being able to do inter-domain
> > > resolving) would allow for this, but I *really* don't think it'll
> > > work well.
> > >
> > > Reasoning is, how do you know that pkg xyz is actually the package
> > > you're after?
> Re-inserted the quote to clarify what I'm talking about; mapping another
> pkg managers db into our own requires either a lot of human
> intervention, or some dodgy rules that somewhat manage it, with bugs.

OK, I see what you mean. You're asking, how does portage know that vendor 
package xyz is the portage package abc?

Short answer is package.mask, meta-packages and name mapping.

A particular vendor package version is a known-good dep, as tested by 
devs, otherwise it is masked. E.g. package.mask says
>vendor-sun/app-arch/cpio-x.y.z if no higher version has been tested. In
mac os, automated updates mean that most of the time, there will be some 
vendor packages that the tree hasn't been tested against. These have to be 
masked until the user does emerge sync.

Another part of the problem is solved by meta-packages. If the vendor dep 
is still masked after emerge sync, it can't be used, and the next most 
"package.preferred" dep will be built and installed straight from the tree 
(on a prefix). Once the vendor dep is unmasked, depclean will remove it 
again.

Virtuals/meta-packages already permit a bit of slack. The packages that 
provide a virtual are not the same, of course, so any ebuild using a 
virtual/meta-package as a dep is not going to be too fussy (e.g. needs awk 
but not gnu extensions). vendor packages are a good fit here.

> > Not sure I understand the problem... in glep 37, a virtual is replaced
> > with a meta-package having a list of depends alternatives. If you add
> > the vendor package to that list, and then make the vendor packages
> > "package.preferred" where portage is a secondary package manager,
> > surely there is no question that package xyz is the one you're after?
> >
> > (I'm assuming all repos share the same namespace WRT package names...
> > if cpv's do not have to be unique accross repos, other solutions might
> > be possible...)
> If you're managing a list of provided packages, my points don't matter;
> points were strictly in reference to trying to have portage query
> another pkg manager (primary or otherwise) :)

BTW, do repos share a namespace? Presented with the same cpv in several 
repos, is portage's behaviour defined yet?

> > > The expanded restrictions subsystem, specifically ability to depends
> > > based on contents restrictions (I want the pkg that owns file abc
> > > essentially) gives basic ability for this
> >
> > I don't understand why portage would go looking for deps in the
> > filesystem. If configure can't find them, does it help that portage
> > can?
> Quote above is in reference to the (potentially incorrectly perceived)
> idea of directly querying another pkg manager.
>
> > The last I read about this was here...
> > http://article.gmane.org/gmane.linux.gentoo.devel/28154 I guess there
> > is more too it?
> Haubi's glep/patches were moreso for pulling off shifted presets,
> relevant to the shifted preset goal's y'all have, but not pertinent to
> portion of the discussion involving attempting to query apple's
> installed db (which is the proposal you put forth) :)
>
> > But, generating package.provided with a wrapper is a hack, so long
> > term, a vendor package manager (or a shim on top of it)
> My question/concerns raised have been regarding the potential
> shim/wrapper.  How do you wrap their pkg manager's namespace into
> portages namespace?  To do so you need to either manage a list of
> mappings yourself, or come up with rules (which will have exceptions).

My feeling is that the burden of managing the mappings is better than the 
burden of managing one package.provided for mac os 10.3, alongside another 
for 10.4, etc. (If I'm wrong about that, then this exercise is pointless.)

In some cases the mapping is trivial: take the closed source XCode 
package. I would have an ebuild called vendor-apple/sys-devel/xcode-1.5 to 
install the DeveloperTools.pkg file, from a distfile taken from apple's 
cd. So this ebuild would contain the forward mapping, by storing the 
vendor's name in it's env. (Same applies to solaris pkgadd and irix 
swinst...)

So the same ebuild also embodies the reverse mapping, and portage can map 
a vendor's package-version to the ebuild itself, and populate a vdb with 
the ebuild's PV. IOW, the ebuilds themselves provide the 1:M mapping of 
vendor name to portage names.

Several vendor packages are sometimes required to make up one of portage's 
deps (e.g. vendor-apple/x11-base/xfree would comprise both of X11SDK.pkg 
and X11User.pkg). That ebuild would install two vendor packages and 
contain two vendor names (basically an N:1 mapping).

Now, what if there is no ebuild to match a vendor package? No mapping. Dep 
has to come from the tree instead. Not a big deal for a secondary package 
manager.

But what if you want dev-tcltk/tcllib to satisfy an explicit dep on 
vendor-apple/dev-tcltk/tcllib? You can't. But I can't see this being a 
problem. (Though, you could have a metapackage for tcllib and 
package.prefer dev-tcltk/tcllib in your profile.)

I would say that explicit deps on vendor packages can be avoided whereever 
said package is open source and we have an ebuild to build it.

Of the open source stuff, those packages that are built from vendor 
sources (or patches), are not "vendor packages" in the sense I've used the 
term, that is, they don't get installed by a foriegn package manager, and 
they don't live under /vendor-*. They are just regular ebuilds.

> That's what I'm getting at; people don't support interop between dpkg
> and rpm (fex) due to the fact the namespaces are different (although
> it's possible to do so if you account for abi).
>
> > I probably need a better handle on the constraints of the relations
> > between domains, repos, prefixes... anyway, here is my naive partial
> > config. This config is premature, of course, but it might help me
> > understand what is and is not possible in the rewrite if you would
> > kindly shoot some holes in it ;-)
> >
> > Notes: I've used a hypothetical feature for collecting information
> > about vendor packages -- presumably the apple domain also needs an
> > ephemeral vdb to hold it (like package.provided). I don't know if this
> > vendor domain needs a repo. I guess the main repo would have to mask
> > broken/testing vendor deps as it sees fit, including those from other
> > domains...
> Offhand, what you're proposing (querying the vendor installed pkg db) is
> actually a readonly vdb, if it were implemented. It's an installed
> package database you can query (use for solving deps), but cannot
> modify.
>
> > [vendor-apple] type = config FEATURES = "query-apple-packages"
> > ACCEPT_KEYWORDS = "ppc-darwin"
> Definitions not totally right as mentioned (doesn't matter, just being
> nitpicky :), but the crux of my concern is embodied inthe
> FEATURES="query-apple-packages".
>
> Mainly, how?  How to query the vendor db, and map that back into portage
> package namespace?

Did I read something about the rewrite being modular? Could the shim/query 
take the form of a portage plugin that implements the query-apple-packages 
feature? Obviously, if implemented the way I descibed above, it would need 
to be intimate with certain ebuilds' environments.

-f

>
> ~harring
>
-- 
gentoo-osx@g.o mailing list