Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Michael Haubenwallner]

Jason Stubbs wrote:
<snip>
> I intend that the package to be installed should not assume anything about
> where its dependencies are and should query portage for them all.

Oh no, now many things get much clearer to me :(

But - aren't there many settings left over to the packages to decide,
at least to choose the package-defaults ?

> 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.

Agreed.
You intend to use some portage-API in ebuilds which knows where and how
to look for dependencies, did i get this right ?
But having portage to behave differently seems crazy to me though.

> 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.

Disagreed - binary packages right now can only be shared between highly
identical machines...

It seems that there are two philosophies of how packages find their
dependencies:

1) The Gentoo-Linux one:
   All the depency information comes from the package manager and is
   passed to packages by commandline, skipping the whole
   autoconf-intelligence.

pro:
+ The patching required for packages is less complex, most of the
    time the autoconf-intelligence has to be disabled if there's a
    commandline parameter missing for a particular feature.

contra:
- To get this work on different platforms, an autoconf alike
    intelligence has to be re-implemented to portage and the ebuilds,
    including access to provided/injected packages or to the
    primary pkg mgr's database.

- External packages installed by hand into the primary prefix will not
    be stored in the primary pkg mgr's database and therefore cannot
    be seen by portage as the secondary mgr once portage could read it.

- There's always a rest of decicions left to the package's
    autoconf-intelligence.

- This works for the primary package mgr, but would become
    unmaintainable for secondary installations - which is your
    legitimate fear.

- Different behaviour seems to be required within the ebuilds or
    (through an API) portage if installed to / or prefix or ~.

2) The one necessary for secondary installation:
   Let the packages decide from environment (PATH,PKG_CONFIG_PATH,...)
   and filesystem where to find their dependencies, and the package
   manager just has to prepare the environment variables and the
   filesystem to let the autoconf intelligence work.

pro:
+ Many of the packages already do compile and run on several platforms,
    by checking the environment and filesystem, and are shipped with the
    autoconf-intelligence required for that.
    This intelligence is used and therefore not needed in portage and
    ebuilds.

+ This is what autoconf/libtool are created for.

+ If there are external packages installed by hand into the primary
    prefix, they are normally recognized, because they appear on the
    filesystem and in the environment.

+ When installing within a primary portage, this continues to work.

+ The pkg mgr does nearly the same commands as an administrator likes to
    do by hand if she has no pkg mgr at hand:
       ./configure [--prefix=/my/prefix]
       make
       make install [DESTDIR=/tmp/inst]
    without any more arguments ideally.

+ Seems to be much less need for ebuild/portage to behave differently if
    installed to / or prefix or ~

contra:
- If the autoconf-intelligence does not work, there's more effort needed
    to create the patches to get it work.

- There's always a rest of issues needed to be dealt with in some
    ebuilds.


Portage itself does not predetermine which philosophy to use - it is to
the ebuild-dev to choose one - but maybe portage's full-support for the
former "doesn't exist and isn't going to exist for a very long time, if
ever" (to say it with ciaranm's words).

To me now, my real problem seems to be the philosophy established
in the ebuild-devs right now, could that be the case ?

> 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.

Agreed, but just to ensure unterstanding:
One thing is the dependency tree for the pkg mgr to install all the
prerequisites, the other is how packages then find those prerequisites,
right ?

>>>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.

When installing a package into ~, a dependency install to / or prefix
becomes triggered or sth. like that, do you mean this ?

> 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.

Agreed from your point now since i know the Gentoo-Linux philosophy of
what ebuilds have to know and what packages are allowed to know (see
above).

Since i've never installed plugins into my ~, some questions here:

Can those plugins be installed into prefix or / too ?

If so, what are the general differences in how to do that against
installing 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've not used cross-compiling yet, but there are cross-compiling bits in
the ebuilds - so what does not work now or how can these bits work now ?

> 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.

I want to distinguish between the effort for portage itself, which does
not immediately hit the ebuilds - it's just a portage-feature not used
by the gentoo-ebuild-tree - and the effort to get ebuilds supporting
prefix/home install.

There's always the way to have a separate ebuild-tree for prefix-
installation, not containing ebuilds for linux-kernel and the like...

~haubi
-- 
Michael Haubenwallner                    SALOMON Automation GmbH
Forschung & Entwicklung                  A-8114 Friesach bei Graz
mailto:michael.haubenwallner@×××××××.at  http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html
-- 
gentoo-dev@g.o mailing list