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
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
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
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
> > [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
> 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.
firstname.lastname@example.org mailing list