On Thursday 19 May 2005 17:18, Michael Haubenwallner wrote: > Jason Stubbs wrote: > > 2 Portage needs to be enhanced with new ebuild support functions for > > detecting the location of a dependency. > > Did you intend this to be needed for those deps to be installed from the > ebuild-tree into the same prefix, or for external deps to be > provided by the system (fex libc, kernel-headers and the like) ?
I intend that the package to be installed should not assume anything about
where its dependencies are and should query portage for them all. Requiring
ebuilds to have special handling for when their dependencies are in the same
${PREFIX} and when in a different ${PREFIX} just seems crazy to me.
> For the former, `portageq` or even ${PREFIX} should work,
> for the latter, why are package.provides (aka injections) insufficient ?
If portage doesn't tell the packages what to build against, they'll go their
own merry way which would definitely make the binary packages mentioned below
impossible.
> Well, one could think of some kind of portage-plugins for querying
> external package managers, fex a wrapper to query the rpm-database
> (app-portage/portageq-rpm, selected by profile), and you might need
> them for home-support, but not necessarily for prefix-support.
Until portage supports other package formats, an equivalent of
package.provided would be used for this. However, this has nothing to do with
how ebuilds would find out where their dependencies are.
> > 6 Portage must disallow the creation of binary packages where all
> > dependencies are not in the same PREFIX.
>
> Hmm, libc, and at least kernel-headers, might rarely be in the same
> prefix but they are provided (injected), but why not build a binary
> package if so ?
> Of course, a binary-package has to be marked with sth. like the
> target-triplet "${CTARGET:-${CHOST}}" and PREFIX it was built for.
I talked with Brian about this and it does seem reasonable. However, the
implementation details will be complex to say the least.
> > 7 Portage needs to be able to configured with one-way dependency
> > allowance between installed package databases. For example, ~ installed
> > packages are allowed to depend on / installed packages.
>
> To get this work, imo the portage-plugins to query external pkg-mgr's
> are required (see item 2 above), as '/' might not be managed by portage.
No need to jump to implementation details yet. You haven't scoped out the full
requirements yet.
> > So unless it is shown otherwise, home install support requires:
>
> But imo the home-support _really_ requires another glep, as there
> are lots of more issuses than for the prefix-support.
This is just silly, in my opinion. Home-support may have issues beyond
prefix-support, but most of them are the same. Why would you only want to
consider prefix-support and implement it if considering home-support might
invalidate assumptions you make? Doing this pathspec stuff is a huge project
so it's not something that should be rushed into.
Doing it properly should also lay down most of the ground work for getting
full cross-compile support into portage as well. Personally, I wouldn't push
this GLEP for approval at all until those issues are at least looked and
fleshed out a bit as well.
I'll reiterate; doing this is a huge amount of work. There really needs to be
a guarantee that the effort will be worth it. And to be honest, if the only
benefit is prefix-support then most everybody will consider the effort to
outweigh the return.
Regards,
Jason Stubbs
pgpyJfrqQf2B0.pgp
Description: PGP signature
