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

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

[Michael Haubenwallner]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

Hi ebuild devs,

Here's a glep draft now for (a part of) the long-term portage-goal
"act as a secondary package manager" ...

Comments welcome,
  haubi
-- 
Michael Haubenwallner                    SALOMON Automation GmbH
Forschung & Entwicklung                  A-8114 Friesach bei Graz
mailto:michael.haubenwallner@salomon.at  http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html


[-- Attachment #2: glep-87877.txt --]
[-- Type: text/plain, Size: 5128 bytes --]

GLEP: XXX
Title: Portage as a secondary package manager
Version: $Revision: 1.5 $
Last Modified: $Date: 2005/04/27 09:29:06 $
Author: Michael Haubenwallner <michael.haubenwallner@salomon.at>
Status: Draft
Type: Standard Track
Content-Type: text/x-rst
Created: 25 Apr 2005
Post-History:


Abstract
========

When administrators have to compile and install third party packages on their
unix systems, most of the time they want to install them in a prefix other than
``/usr``. The common example is ``/usr/local``.

This document is intended to describe how to write ebuilds to work with both
primary (prefix ``/usr``) and secondary (other prefixes) portage instances,
and how portage has to be modified to get able to act as a secondary package
manager too.


Motivation
==========

Right now, many of the administrators do maintain their self-compiled packages
even manually or with their own scripts.

As portage is already a package manager for a source-based Linux distribution,
the idea is to use it also as a secondary package manager for prefixes other
than ``/usr``.


Rationale
=========

Currently, ``/usr`` is used hardcoded as the prefix in the ebuild-tree,
unless the portage provided functions econf/emake and the like are used.
If so, the prefix setting is delegated to those functions.

To get a prefix under portage's control, a portage instance has to be installed
into this prefix. To perform this install, just have recent python and bash
installed somewhere in PATH (they need not to be installed in destination
prefix) and install portage like most of other open source packages::

 $ bunzip2 < portage-XXX.tar.gz | tar xf -
 $ cd portage-XXX
 $ ./configure --prefix=/new/prefix
 $ make
 $ make install

Portage will create its own database there [#vdb]_.
This document prefers a filesystem hierarchy under this prefix as close as
possible to the current filesystem hierarchy used in Gentoo Linux [#FHS]_.

After setting up an ebuild-tree there and tweaking the parameters in
``/new/prefix/etc/make.conf``, ebuilds supporting such an installation can be
proceeded with this just installed portage. The ebuilds will install their
packages into the same prefix as portage is installed.


Changes for ebuilds
===================

Portage will provide an environment variable ``PREFIX``, containing ``/usr``
when acting as the primary package manager (as in Gentoo Linux), or the prefix
it is installed to when acting as the secondary package manager for that prefix.

There are some difference between prefix ``/usr`` and other prefixes:
``/usr`` has its configuration-files, state-dirs and others in ``/``
(as ``/etc``, ``/var``, ``/other``) while ``/new/prefix`` has them directly in
``/new/prefix`` (as ``/new/prefix/etc``, ``/new/prefix/var``,
``/new/prefix/other``).

So there is one more variable needed to be set by portage to get the pathes
right for those dirs residing in ``/`` for prefix ``/usr``. This variable is
called ``AFFIX``, and is empty for prefix ``/usr``, but set to ``new/prefix/``
for prefix ``/new/prefix``, and to ``usr/local/`` for prefix ``/usr/local``.

The difference for the ebuild now is to use ``${PREFIX}`` and ``/${AFFIX}``
instead of hardcoded ``/usr`` and ``/``, like this::

   src_compile() {
 -     ${S}/configure --prefix=/usr --sysconfdir=/etc
 +     ${S}/configure --prefix=${PREFIX} --sysconfdir=/${AFFIX}etc
       make
   }

And of course, a new keyword [#keyword-glep]_ has to be added to the ebuild
to get a package unmasked for a platform where portage acts as a secondary
package manager.


Backwards Compatibility
=======================

To keep ebuilds working with old portage versions not setting PREFIX and AFFIX,
the default value for ``PREFIX`` can be set within the ebuild-tree in
``profiles/base/profile.bashrc`` like this::

 [[ -z $PREFIX ]] && PREFIX=/usr
 export PREFIX

The default value for ``AFFIX`` is empty and needs not to be set explicitly.


Implementation
==============

A patch for portage to set ``PREFIX`` and ``AFFIX`` can already be found in
gentoo bugzilla [#bgo87877]_.


References
==========

.. [#vdb] ``${PREFIX}/var/db/pkg``, for example ``/new/prefix/var/db/pkg``.

.. [#FHS] http://www.pathname.com/fhs/ with one exception:

    FHS-2.3 says the variable data dir for ``/usr/local`` resides in
    ``/var/local``, and in ``/var/opt`` for prefix ``/opt`` while this
    document will install them to ``/usr/local/var``, ``/opt/var`` or even
    ``/new/prefix/var``.

    But there's also a possibility in FHS-2.3 to have ``/var/local`` and
    ``/var/opt`` as softlinks somewhere to ``/usr/local/var`` and ``/opt/var``,
    and it's not defined if one installs a tree in ``/new/prefix``
    that the variable data should go to ``/var/new/prefix`` instead of
    ``/new/prefix/var``.

    Maybe this is what Gentoo developers call "pathspec" ?

.. [#keyword-glep] GLEP 22, New ``keyword`` system to incorporate various
   userlands/kernels/archs (http://glep.gentoo.org/glep-0022.html)

.. [#bgo87877] http://bugs.gentoo.org/show_bug.cgi?id=87877


Copyright
=========

This document has been placed in the public domain.

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Mon, 02 May 2005 14:22:15 +0200 Michael Haubenwallner
<michael.haubenwallner@salomon.at> wrote:
| Hi ebuild devs,
| 
| Here's a glep draft now for (a part of) the long-term portage-goal
| "act as a secondary package manager" ...

Why did you post this without addressing the problems I pointed out to
you previously? Writing something up as a GLEP doesn't magically fix all
the holes in it.

Oh, and by the way, we don't follow FHS.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Jackson]

Michael Haubenwallner wrote:

>Hi ebuild devs,
>
>Here's a glep draft now for (a part of) the long-term portage-goal
>"act as a secondary package manager" ...
>
>Comments welcome,
>  haubi
>  
>
It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo?

-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

On Mon, May 02, 2005 at 03:13:56PM +0100, Ciaran McCreesh wrote:
> On Mon, 02 May 2005 14:22:15 +0200 Michael Haubenwallner
> <michael.haubenwallner@salomon.at> wrote:
> | Hi ebuild devs,
> | 
> | Here's a glep draft now for (a part of) the long-term portage-goal
> | "act as a secondary package manager" ...
> 
> Why did you post this without addressing the problems I pointed out to
> you previously? Writing something up as a GLEP doesn't magically fix all
> the holes in it.
State said problem for the general community.  Guessing you're 
referencing the issue/request that being able to manage home, and 
'global' installations?

I'd still posit that the issue of installing to a user's home when 
portage's base prefix is /usr/local (fex) is a seperate issue.  What 
you were requesting for vim plugins goes beyond haubi's initial 
goals...


So yeah, restate the issues in the ml so people can weigh in, 
alternative approachs/solutions, etc.
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Jackson wrote:
> Michael Haubenwallner wrote:
> 
> 
>>Hi ebuild devs,
>>
>>Here's a glep draft now for (a part of) the long-term portage-goal
>>"act as a secondary package manager" ...
>>
>>Comments welcome,
>> haubi
>> 
>>
> 
> It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo?
> 
ROOT doens't work for DEPENDS, only [R,P]DEPENDS which means I can't
install everything for pkg FOO in ROOT="/opt" fex.  Mostly useful for
alt arches when /usr is taken by the primary OS and you need portage's
DEPEND packages to go somewhere else.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQnbMxWzglR5RwbyYAQJR7BAAmi8n2DGmN+icAJODkYQQYhLDmK+AJe86
aGS2sp2gtVufZEIjDWixtmOvxnNb4i5WSwxHCFI3sRK0WdtshFjMOVaPDoajnnUk
QAEsExe90DLiwQQN55BABjC3x5kKLhuyEpH3MYMQOrv1lGOclD3j/jRRoVgakBJF
YF7o0LIEZNSeby9cqTWzBx9G+4WgLVtAFBkKc7NqvqusYuyEWr2MI7eI0D8WuEXT
BZfB1uJtKbLXBbtUNbOYAxYOnGvQieKTVErlg+Of+7qsoX3fiYn9Y09ERIK5qRQ0
k4lIwZ+75bRiANvgfBQM90G87fUTgJsIuXmVhrVc0Z4L4tfIcFuVvV16w9efiY91
JVxkUCrb8ZJPI8ScIv/sPUWAkzSKYL66xtMaVhzyeT4E6ZPD7mZcNGFu4D/oNL1Z
CpDlrkuIuBWTJOCz3vlG4bm4x9HWFi44ukq8bFMr0iiimPicJW+QoTpvZKhnMaSC
mdy7Z/rAcsIvnwcQRgcmJeCAmQQ1xVz/h/X4AyMMApAwVAFgzFvEWC7AWnxCAGMd
EVTX7D5paNA3yia9nDkEcJ1ryNhjEEQ83lFwtcRnlXNDuRQ/9bk/XzLBPXONMhye
n8rK8v+xcn0bGgjG9s2wwiMSxTQWxibqY4CB0DZR43KsL+jw3MD0B34HAbTBPE19
+mxWlsBDV+U=
=8uFj
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Jackson]

On Mon, 2005-05-02 at 20:58 -0400, Alec Warner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brian Jackson wrote:
> > Michael Haubenwallner wrote:
> > 
> > 
> >>Hi ebuild devs,
> >>
> >>Here's a glep draft now for (a part of) the long-term portage-goal
> >>"act as a secondary package manager" ...
> >>
> >>Comments welcome,
> >> haubi
> >> 
> >>
> > 
> > It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo?
> > 
> ROOT doens't work for DEPENDS, only [R,P]DEPENDS which means I can't
> install everything for pkg FOO in ROOT="/opt" fex.  Mostly useful for
> alt arches when /usr is taken by the primary OS and you need portage's
> DEPEND packages to go somewhere else.

Well, I've got a bug open to have a different variable like ROOT that
portage would read config files from. Maybe you could jump on that
bandwagon, and see if you can make things work that way.

I just don't see the uptake to fix a very large portion of the tree for
something that I'd guess most devs think is pointless. That's also the
reason the "enterprise" tree hasn't taken off.

People working in their free time couldn't give a crap about people
thinking Gentoo isn't suitable for enterprise applications. In fact, I'd
bet there are even some people that already do or would sabotage such an
effort.

If you want to use portage, use Gentoo. If you want some package manager
for your solaris/x86 box(just an example!), go talk to the people that
do openembedded. They are geared toward using it as a secondary package
manager on a system.

--Iggy

-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]

On Mon, May 02, 2005 at 09:11:03PM -0500, Brian Jackson wrote:
> Well, I've got a bug open to have a different variable like ROOT that
> portage would read config files from. Maybe you could jump on that
> bandwagon, and see if you can make things work that way.

Assuming you're referencing CONFIG_ROOT, it frankly isn't much of a 
solution for his needs.  The problem with CONFIG_ROOT is you would 
have to set it for every emerge invocation.  His intention is to have 
portage function from a variable prefix, and install to a build time 
defined prefix.  IOW, portage using different paths on an installed 
box, not portage installed to it's normal location, and hacked up via 
an environment variable to try and change the behaviour.

I'm not much for config_root, obviously.  The intention of it, and 
varying root (imo) is a hack around portage's expectations about it's 
configuration and repos.  It's not much of a proper solution.


> I just don't see the uptake to fix a very large portion of the tree for
> something that I'd guess most devs think is pointless. 

Aparently people didn't notice the multilib changes passing through 
the tree the last few months?  Same type of wide spread change, yet 
it's being done, and ebuilds are being migrated.  Things break, but 
the party/person interested in adding the support is doing the work.

Sidenote re: fixing a large portion of the tree, eclasses and 
portage's base template for ebuilds would be the first start in 
terms of changes.  That 'very large' portion of the tree arguement 
would be ixnayed via that, what would remain is a collection of 
pissy packages that need manual tweaking.


> That's also the
> reason the "enterprise" tree hasn't taken off.
> People working in their free time couldn't give a crap about people
> thinking Gentoo isn't suitable for enterprise applications.

The reason for the enterprise tree not being ready/finished, or even 
*accepted* (it _still_ is a draft after all) is frankly no ones fault 
but those who want such a tree.  The reason glep25 (my own glep) isn't 
implemented is again, no ones fault but those pushing it (read: me).  
Might want to clarify what you're asserting, cause I'm not seeing the 
validity in it...

So... yeah, the enterprise angle imo is slightly daft.  If you're 
arguing that their are more 'important' things to do rather then this, 
state it as such, or please clarify...


> If you want to use portage, use Gentoo. 

That should be "or put in the grunt work to support it".  If I recall 
correctly, you're working on gentoo embedded.  The arguements you're 
leveling above could just as easily be used against expanding the tree 
to support uclibc, or a slightly saner example, dropping osx support 
(portage _is_ the secondary manager there).  Hell, y'all are in a 
similar boat, for actual device updating you'll be using emerge.c, 
which _isn't_ portage, just compatible with the binpkg support.  

Either way, my point is that portage/gentoo will flow into the niche's 
people care to expand it into.  It's pointless telling them not to do 
it, because they _will_ do it anyways if it makes sense to them.  So 
point out the failings, or better solutions.

Yeah, time for me to step down from the soapbox I think...

> If you want some package manager
> for your solaris/x86 box(just an example!), go talk to the people that
> do openembedded.

Clarify why portage, which _does_ function as a secondary pkg manager 
(collision-protect wouldn't exist otherwise) wouldn't suffice if 
someone gave enough of a damn to do the work?

So yeah, anyone care to comment about the proposal's specifics, rather 
then "piss off, no..." ?  :)
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Jackson]

On Mon, 2005-05-02 at 21:48 -0500, Brian Harring wrote:
<snip>
> 
> > If you want some package manager
> > for your solaris/x86 box(just an example!), go talk to the people that
> > do openembedded.
> 
> Clarify why portage, which _does_ function as a secondary pkg manager 
> (collision-protect wouldn't exist otherwise) wouldn't suffice if 
> someone gave enough of a damn to do the work?
> 
> So yeah, anyone care to comment about the proposal's specifics, rather 
> then "piss off, no..." ?  :)

No, that pretty much sums up how I feel about it and all these other pet
projects that keep popping up (I'm guilty of a few myself... s390
anyone?). The ones that make it. Cool, good for you. The other 98% of
them would have been better off if they had me disuading them to begin
with.

--Iggy

> ~brian

-- 
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Mon, 2 May 2005 21:48:10 -0500
Brian Harring <ferringb@gentoo.org> wrote:

> Clarify why portage, which _does_ function as a secondary pkg manager 
> (collision-protect wouldn't exist otherwise) wouldn't suffice if 
> someone gave enough of a damn to do the work?

Off-topic, but collision-protect wasn't written for that purpose but to
detect broken/conflicting packages. The macos project just uses it.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Michael Haubenwallner]

Brian Harring wrote:
> On Mon, May 02, 2005 at 03:13:56PM +0100, Ciaran McCreesh wrote:
<snip>
>>Why did you post this without addressing the problems I pointed out to
>>you previously? Writing something up as a GLEP doesn't magically fix all
>>the holes in it.
> 
> State said problem for the general community.  Guessing you're 
> referencing the issue/request that being able to manage home, and 
> 'global' installations?
> 
> I'd still posit that the issue of installing to a user's home when 
> portage's base prefix is /usr/local (fex) is a seperate issue.  What 
> you were requesting for vim plugins goes beyond haubi's initial 
> goals...

Exactly that, and according to glep 1 a glep should address just *one*
problem at once...

IMO a secondary package manager just has to manage the files/packages
installed into the same prefix the pkgm is installed to, nothing else.
If you want to use a pkgm for ~, then set up a pkgm with prefix=~,
and use an ebuild-tree or profile containing packages dedicated to
be installed into ~.

And once portage is able to act as a secondary pkgm, this does not imply
that the whole ebuild-tree makes sence to install with a 2nd pkg mgr,
fex baselayout, which is already virtualized for baselayout-lite
(eh, what is Linux VServer ?).

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


-- 
gentoo-dev@gentoo.org mailing list

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

[Michael Haubenwallner]

Alec Warner wrote:
> Brian Jackson wrote:
>>>It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo?
> ROOT doens't work for DEPENDS, only [R,P]DEPENDS which means I can't
> install everything for pkg FOO in ROOT="/opt" fex.  Mostly useful for
> alt arches when /usr is taken by the primary OS and you need portage's
> DEPEND packages to go somewhere else.

It's not just the DEPENDS: an executable built with ROOT=/usr/local
becomes *copied/extracted* into /usr/local/usr/bin, but it _knows_
(compiled in) to run from /usr/bin.
ROOT is intended to "cross-bootstrap" (better words?) a stage{1,2,3} or
the like to be copied to another box - or used with 'chroot /usr/local',
which is not what i understand as how to use a secondary pkgm.

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

-- 
gentoo-dev@gentoo.org mailing list

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

[Michael Haubenwallner]

Brian Harring wrote:
> Sidenote re: fixing a large portion of the tree, eclasses and 
> portage's base template for ebuilds would be the first start in 

The work for eclasses is already done at all (less bugs), will
post them (where? bug 87877? new bug?) once glep is accepted.

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


-- 
gentoo-dev@gentoo.org mailing list

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

[Michael Haubenwallner]

Ciaran McCreesh wrote:
>
> Oh, and by the way, we don't follow FHS.

This makes things easier, so what's better - to omit this completely,
or just say (without a reference to FHS):
"This document prefers a filesystem hierarchy under this prefix as close
as possible to the current filesystem hierarchy used in Gentoo Linux."

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

-- 
gentoo-dev@gentoo.org mailing list

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

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

On Monday 02 May 2005 21:22, Michael Haubenwallner wrote:
> Hi ebuild devs,
>
> Here's a glep draft now for (a part of) the long-term portage-goal
> "act as a secondary package manager" ...

How about packages that usually install into "/"?

Regards,
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

On Mon, 2 May 2005 19:02:29 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| State said problem for the general community.  Guessing you're 
| referencing the issue/request that being able to manage home, and 
| 'global' installations?
| 
| I'd still posit that the issue of installing to a user's home when 
| portage's base prefix is /usr/local (fex) is a seperate issue.  What 
| you were requesting for vim plugins goes beyond haubi's initial 
| goals...

Ok, here's the main issue. Simply changing prefix isn't enough to
automatically make every package in the tree work. A heck of a lot of
them will need manual modification, and there's no easy way to figure
out which these are. So...

My suggested way around this was to have a variable in ebuilds. Call it
something like ICANINSTALLTO (that name sucks, come up with something
better), which defaults to ICANINSTALLTO="usr". Ebuilds which have been
explicitly checked and designed by the maintainer for prefix installs
get ICANINSTALLTO="usr prefix".

This also allows us to do other cool stuff like ICANINSTALLTO="home",
for things like vim and gkrellm plugins which can go in ~/.vim/ and
~/.gkrellm2/plugins/ respectively.

Thing is, if we introduce the PREFIX feature, people will expect it to
actually work. It won't, at least not straight away, because there are
so many ebuilds that use more than econf to get the prefix figured out.
By whitelisting we can at least display a nice "you can't install this
package in a prefix" message.

Another issue... Portage installs to /usr/local are no good, because
there might be other non-portage installs there too. If we're installing
to a prefix, we have to be the *only* thing installing there. No other
packages, not even other manual installs.

Yet another issue... As it stands, all deps must be installed into the
given PREFIX. This is messy. Is there a way around this? This would be
less of a problem with ICANINSTALLTO="home" -- presumably for these
portage could pass a var to the ebuild telling it in which prefix to
look for its deps.

That'll do for now. I'll shoot some more holes in it once these have
been figured out.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

On Tue, May 03, 2005 at 03:12:20PM +0100, Ciaran McCreesh wrote:
> On Mon, 2 May 2005 19:02:29 -0500 Brian Harring <ferringb@gentoo.org>
> wrote:
> | State said problem for the general community.  Guessing you're 
> | referencing the issue/request that being able to manage home, and 
> | 'global' installations?
> | 
> | I'd still posit that the issue of installing to a user's home when 
> | portage's base prefix is /usr/local (fex) is a seperate issue.  What 
> | you were requesting for vim plugins goes beyond haubi's initial 
> | goals...
> 
> Ok, here's the main issue. Simply changing prefix isn't enough to
> automatically make every package in the tree work. A heck of a lot of
> them will need manual modification, and there's no easy way to figure
> out which these are. So...

Err.  ROOT!="/" exists already, and directly screws with prefixes.  So 
this doesn't seem particularly valid in light of that fact.

> My suggested way around this was to have a variable in ebuilds. Call it
> something like ICANINSTALLTO (that name sucks, come up with something
> better), which defaults to ICANINSTALLTO="usr". Ebuilds which have been
> explicitly checked and designed by the maintainer for prefix installs
> get ICANINSTALLTO="usr prefix".

I'd be curious about the _actual_ number of packages that lose their 
asses when the base prefix is not /usr in light of root tomfoolery 
mentioned above.

Note, I'm not talking about installing plugins to a seperate prefix 
within a managed domain (portage as the primary pkg manager, '/' is 
it's domain effectively).


> This also allows us to do other cool stuff like ICANINSTALLTO="home",
> for things like vim and gkrellm plugins which can go in ~/.vim/ and
> ~/.gkrellm2/plugins/ respectively.

Regarding specifying 'targets', yes, with limits, although I don't 
think it's a valid arguement (currently) against haubi's proposal.  

Reasoning is thus, root already directly screws with the prefix for a 
good collection of packages.  What you're after above is a way to 
specify multiple prefixes for a single portage installation

Falling back to portage as the primary pkg manager, you basically seem 
to be after

emerge --target home vim-plugin
vs
emerge --target default vim-plugin

default being use or use/local or whatever the hell

So... short version, ICANINSTALLTO is down the line.  Baby steps.  
What you're after above requires haubi's modifications, and _more_.  
Peg off the issues one by one to get to ICANINSTALLTO="home", instead 
of trying to pull it all off in a single magic bullet.

> Thing is, if we introduce the PREFIX feature, people will expect it to
> actually work. It won't, at least not straight away, because there are
> so many ebuilds that use more than econf to get the prefix figured out.
> By whitelisting we can at least display a nice "you can't install this
> package in a prefix" message.

Not a valid arguement to exempt even trying.

Consider if people used that arg for avoiding porting linux to new 
arches-  Linux would still be strictly x86.


> Another issue... Portage installs to /usr/local are no good, because
> there might be other non-portage installs there too. If we're installing
> to a prefix, we have to be the *only* thing installing there. No other
> packages, not even other manual installs.

Collision-protect anyone? :)

Seriously though, if they're using portage as a secondary manager and 
using other pkg managers that install to /usr/local, it's the 
admin's responsibility to handle it.  The proposal isn't requesting we 
go querying through rpm's db to make sure we're not stomping anything, 
it's goal is to extend portage (and ebuild conventions) so that _using_ 
it as a secondary manager w/out installing to / is viable.

So... easy hole in that arguement is having each secondary manager use 
it's own base prefix.


> Yet another issue... As it stands, all deps must be installed into the
> given PREFIX. This is messy. Is there a way around this?  This would be
> less of a problem with ICANINSTALLTO="home" -- presumably for these
> portage could pass a var to the ebuild telling it in which prefix to
> look for its deps.

injections, mainly.

Your ICANINSTALLTO bit, when operating within the same installation 
(see emerge --target bit above) would require multiple vdb's, and 
portage being smart enough to handle N vdbs.

Portage is still stuck in the special classes.  As mentioned above, 
changes to ebuild conventions and changes to portage repository 
handling is required.  Baby steps...

> That'll do for now. I'll shoot some more holes in it once these have
> been figured out.

Fire away, looking forward to the next attempt ;)

~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

On Thu, May 05, 2005 at 03:48:49AM -0500, Brian Harring wrote:
> default being use or use/local or whatever the hell
Wow.
no more posting at 3:50 am...

meant usr for above, pardon.
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

On Thu, 5 May 2005 03:48:49 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| > Ok, here's the main issue. Simply changing prefix isn't enough to
| > automatically make every package in the tree work. A heck of a lot
| > of them will need manual modification, and there's no easy way to
| > figure out which these are. So...
| 
| Err.  ROOT!="/" exists already, and directly screws with prefixes.  So
| this doesn't seem particularly valid in light of that fact.

No, root doesn't screw with prefixes.

| > Thing is, if we introduce the PREFIX feature, people will expect it
| > to actually work. It won't, at least not straight away, because
| > there are so many ebuilds that use more than econf to get the prefix
| > figured out. By whitelisting we can at least display a nice "you
| > can't install this package in a prefix" message.
| 
| Not a valid arguement to exempt even trying.
| 
| Consider if people used that arg for avoiding porting linux to new 
| arches-  Linux would still be strictly x86.

Eh? No, see, we have KEYWORDS, which indicate whether you can use a
package on a given arch.

| > Yet another issue... As it stands, all deps must be installed into
| > the given PREFIX. This is messy. Is there a way around this?  This
| > would be less of a problem with ICANINSTALLTO="home" -- presumably
| > for these portage could pass a var to the ebuild telling it in which
| > prefix to look for its deps.
| 
| injections, mainly.

Nasty hack.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

On Thu, May 05, 2005 at 03:01:05PM +0100, Ciaran McCreesh wrote:
> On Thu, 5 May 2005 03:48:49 -0500 Brian Harring <ferringb@gentoo.org>
> wrote:
> | > Ok, here's the main issue. Simply changing prefix isn't enough to
> | > automatically make every package in the tree work. A heck of a lot
> | > of them will need manual modification, and there's no easy way to
> | > figure out which these are. So...
> | 
> | Err.  ROOT!="/" exists already, and directly screws with prefixes.  So
> | this doesn't seem particularly valid in light of that fact.
> 
> No, root doesn't screw with prefixes.

"Which brings me to my next point, kids don't do crack."
I'm pleading temporary insanity on that one.

That said, I'll just point at fink's nonstandard prefix for 
installation as a better example that it *can* be pulled off without 
all of this 'fire, brimstome, and the apocalypse on earth' cruft 
people keep throwing about as an arguement it can't work.

Think about it for a second.  What is the purpose of --prefix, and all 
the other lovely configure installation options?  To configure the 
source so it'll work in it's intended destination.

Yes, it doesn't work perfectly across all packages, and not all 
packages are designed to be flexible in installation (straight 
makefile hacks come to mind, dev-util/bsdiff for example).  This is 
why I keep pointing at the parallel of adding a new arch.  You get 
your core support down, and expand support across the tree as you go.

In other words, yes, there are technical issues, but I _still_ posit 
that those issues are experienced by those who want said support, and 
who are the lucky buggers who have to do the bug squashing.  It's the 
same damn thing macos encounters, and any new arch, hence my complete 
lack of understanding for why people are quick to fire off "piss off, 
it won't work" without looking at the actual issues.


> | > Thing is, if we introduce the PREFIX feature, people will expect it
> | > to actually work. It won't, at least not straight away, because
> | > there are so many ebuilds that use more than econf to get the prefix
> | > figured out. By whitelisting we can at least display a nice "you
> | > can't install this package in a prefix" message.
> | 
> | Not a valid arguement to exempt even trying.
> | 
> | Consider if people used that arg for avoiding porting linux to new 
> | arches-  Linux would still be strictly x86.
> 
> Eh? No, see, we have KEYWORDS, which indicate whether you can use a
> package on a given arch.

Dodging my point.  You stated, "if we introduce it, people will expect 
it to actually work".  It's defeatist logic; won't try because people 
might bitch if they wade into experimental territory and get bit.

That's the point I was getting at, which you seemed to ignore/not 
understand.

Pointing out that people might try an experimental feature and hit 
issues and bitch as a reason for _not_ doing something is just plain 
daft.

The porting of linux to a new arch is a valid analogy there; for the 
person to even try it, they have to venture off the beaten path, past 
many warnings about it being experimental.  If they shoot themselves 
in the foot/hit issues, well, they're big boys/girls and they can fend 
for themselves.

They are, after all, the ones who ventured off the beaten path and 
started screwing with an experimental feature.  It's their 
responsibility, and arguing that we shouldn't attempt something 
because people might bitch is a weak arguement, basically an attempt 
to shoot down the proposal without a valid reason.


> | > Yet another issue... As it stands, all deps must be installed into
> | > the given PREFIX. This is messy. Is there a way around this?  This
> | > would be less of a problem with ICANINSTALLTO="home" -- presumably
> | > for these portage could pass a var to the ebuild telling it in which
> | > prefix to look for its deps.
> | 
> | injections, mainly.
> 
> Nasty hack.

Alternative being what, auto detection of files on disk to map it back 
to ebuild nodes?  I'd posit that's equally nasty.

Call it a hack if so desired, but that's the purpose of 
injections/provided, and is the basis of the osx port from a dep 
resolution standpoint.

If you've got a better suggestion, macos probably would love to know 
of it ;)

So, fink demonstration of --prefix hackery?
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Jackson]

Brian Harring wrote:

>On Thu, May 05, 2005 at 03:01:05PM +0100, Ciaran McCreesh wrote:
>  
>
>>On Thu, 5 May 2005 03:48:49 -0500 Brian Harring <ferringb@gentoo.org>
>>wrote:
>>| > Ok, here's the main issue. Simply changing prefix isn't enough to
>>| > automatically make every package in the tree work. A heck of a lot
>>| > of them will need manual modification, and there's no easy way to
>>| > figure out which these are. So...
>>| 
>>| Err.  ROOT!="/" exists already, and directly screws with prefixes.  So
>>| this doesn't seem particularly valid in light of that fact.
>>
>>No, root doesn't screw with prefixes.
>>    
>>
>
>"Which brings me to my next point, kids don't do crack."
>I'm pleading temporary insanity on that one.
>
>That said, I'll just point at fink's nonstandard prefix for 
>installation as a better example that it *can* be pulled off without 
>all of this 'fire, brimstome, and the apocalypse on earth' cruft 
>people keep throwing about as an arguement it can't work.
>
>Think about it for a second.  What is the purpose of --prefix, and all 
>the other lovely configure installation options?  To configure the 
>source so it'll work in it's intended destination.
>
>Yes, it doesn't work perfectly across all packages, and not all 
>packages are designed to be flexible in installation (straight 
>makefile hacks come to mind, dev-util/bsdiff for example).  This is 
>why I keep pointing at the parallel of adding a new arch.  You get 
>your core support down, and expand support across the tree as you go.
>
>In other words, yes, there are technical issues, but I _still_ posit 
>that those issues are experienced by those who want said support, and 
>who are the lucky buggers who have to do the bug squashing.  It's the 
>same damn thing macos encounters, and any new arch, hence my complete 
>lack of understanding for why people are quick to fire off "piss off, 
>it won't work" without looking at the actual issues.
>
>
>  
>
>>| > Thing is, if we introduce the PREFIX feature, people will expect it
>>| > to actually work. It won't, at least not straight away, because
>>| > there are so many ebuilds that use more than econf to get the prefix
>>| > figured out. By whitelisting we can at least display a nice "you
>>| > can't install this package in a prefix" message.
>>| 
>>| Not a valid arguement to exempt even trying.
>>| 
>>| Consider if people used that arg for avoiding porting linux to new 
>>| arches-  Linux would still be strictly x86.
>>
>>Eh? No, see, we have KEYWORDS, which indicate whether you can use a
>>package on a given arch.
>>    
>>
>
>Dodging my point.  You stated, "if we introduce it, people will expect 
>it to actually work".  It's defeatist logic; won't try because people 
>might bitch if they wade into experimental territory and get bit.
>
>That's the point I was getting at, which you seemed to ignore/not 
>understand.
>
>Pointing out that people might try an experimental feature and hit 
>issues and bitch as a reason for _not_ doing something is just plain 
>daft.
>
>The porting of linux to a new arch is a valid analogy there; for the 
>person to even try it, they have to venture off the beaten path, past 
>many warnings about it being experimental.  If they shoot themselves 
>in the foot/hit issues, well, they're big boys/girls and they can fend 
>for themselves.
>
>They are, after all, the ones who ventured off the beaten path and 
>started screwing with an experimental feature.  It's their 
>responsibility, and arguing that we shouldn't attempt something 
>because people might bitch is a weak arguement, basically an attempt 
>to shoot down the proposal without a valid reason.
>  
>

Okay, I'll stop shooting. But I suggest that this is a particular GLEP
where a reference implementation (outside of the main portage tree)
would aid people in studying the GLEP. The GLEP workflow section allows
for this. I'd say at least a standard emerge system should be working
before this GLEP is approved.

--Iggy

>
>  
>
>>| > Yet another issue... As it stands, all deps must be installed into
>>| > the given PREFIX. This is messy. Is there a way around this?  This
>>| > would be less of a problem with ICANINSTALLTO="home" -- presumably
>>| > for these portage could pass a var to the ebuild telling it in which
>>| > prefix to look for its deps.
>>| 
>>| injections, mainly.
>>
>>Nasty hack.
>>    
>>
>
>Alternative being what, auto detection of files on disk to map it back 
>to ebuild nodes?  I'd posit that's equally nasty.
>
>Call it a hack if so desired, but that's the purpose of 
>injections/provided, and is the basis of the osx port from a dep 
>resolution standpoint.
>
>If you've got a better suggestion, macos probably would love to know 
>of it ;)
>
>So, fink demonstration of --prefix hackery?
>~brian
>  
>

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]

On Fri, 6 May 2005 00:09:58 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| That said, I'll just point at fink's nonstandard prefix for 
| installation as a better example that it *can* be pulled off without 
| all of this 'fire, brimstome, and the apocalypse on earth' cruft 
| people keep throwing about as an arguement it can't work.
| 
| Think about it for a second.  What is the purpose of --prefix, and all
| the other lovely configure installation options?  To configure the 
| source so it'll work in it's intended destination.
| 
| Yes, it doesn't work perfectly across all packages, and not all 
| packages are designed to be flexible in installation (straight 
| makefile hacks come to mind, dev-util/bsdiff for example).  This is 
| why I keep pointing at the parallel of adding a new arch.  You get 
| your core support down, and expand support across the tree as you go.
| 
| In other words, yes, there are technical issues, but I _still_ posit 
| that those issues are experienced by those who want said support, and 
| who are the lucky buggers who have to do the bug squashing.  It's the 
| same damn thing macos encounters, and any new arch, hence my complete 
| lack of understanding for why people are quick to fire off "piss off, 
| it won't work" without looking at the actual issues.

The problem isn't the packages. The problem is the ebuilds.

| > Eh? No, see, we have KEYWORDS, which indicate whether you can use a
| > package on a given arch.
| 
| Dodging my point.  You stated, "if we introduce it, people will expect
| it to actually work".  It's defeatist logic; won't try because people 
| might bitch if they wade into experimental territory and get bit.
| 
| That's the point I was getting at, which you seemed to ignore/not 
| understand.
| 
| Pointing out that people might try an experimental feature and hit 
| issues and bitch as a reason for _not_ doing something is just plain 
| daft.

Except we have an easy way of marking which ebuilds will actually work
with this thing. Why not use it? It's a hell of a lot cleaner, it gives
us better feedback and it makes it easier for the users.

| If you've got a better suggestion, macos probably would love to know 
| of it ;)

Per-ebuild whitelisting, kind of like KEYWORDS. This has the added
advantage of making it easy for additional kinds of install target to be
added at some point.

| So, fink demonstration of --prefix hackery?

If you want a better example, try either SGI or Sun's GNU tools ports.
But they don't use ebuilds either.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

On Fri, May 06, 2005 at 02:28:49PM +0100, Ciaran McCreesh wrote:
> The problem isn't the packages. The problem is the ebuilds.
Agreed, although seemed to take a bit of dancing to get done to the 
fact that yes, changing the prefix has a good chance of working.

>From there, we're back to the old two step econf/eclasses _do_ address 
a sizable portion of ebuilds in the tree ;)

> | > Eh? No, see, we have KEYWORDS, which indicate whether you can use a
> | > package on a given arch.
> | 
> | Dodging my point.  You stated, "if we introduce it, people will expect
> | it to actually work".  It's defeatist logic; won't try because people 
> | might bitch if they wade into experimental territory and get bit.
> | 
> | That's the point I was getting at, which you seemed to ignore/not 
> | understand.
> | 
> | Pointing out that people might try an experimental feature and hit 
> | issues and bitch as a reason for _not_ doing something is just plain 
> | daft.
> 
> Except we have an easy way of marking which ebuilds will actually work
> with this thing. Why not use it? It's a hell of a lot cleaner, it gives
> us better feedback and it makes it easier for the users.
Not much for a keyword route personally, since (imo) it's a slight 
perversion of the focus of keywords.  If the keywording route was 
taken, would need to either duplicate existing keywords (have 
x86/~x86, and x86-weirdo-prefix ~x86-weirdo-prefix), or require two 
specific keywords being set (x86 and weirdo-prefix from the example 
above).  

I'd suspect your metadata addition (which needs a better name then 
ICANINSTALLTO) is the best route.

> Per-ebuild whitelisting, kind of like KEYWORDS. This has the added
> advantage of making it easy for additional kinds of install target to be
> added at some point.
See above (agreed).

> | So, fink demonstration of --prefix hackery?
> 
> If you want a better example, try either SGI or Sun's GNU tools ports.
> But they don't use ebuilds either.
Well, main point was that the underlying packages _can_ swing this 
type of hackery for the most part, what is needed is a tweak to our 
ebuild conventions to allow for it.

Meanwhile, iirc from the last irc conversation on this, either you or 
dsd brought up the point of needing to be able to query if (using vim 
as an example) vim-core was $home, rather then usr|$PREFIX.  Care to 
elaborate a bit?  Mainly wondering if to encompass your requests, it 
might require extra metadata from the depend standpoint.
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

On Fri, May 06, 2005 at 08:12:07AM -0500, Brian Jackson wrote:
> Okay, I'll stop shooting. But I suggest that this is a particular GLEP
> where a reference implementation (outside of the main portage tree)
> would aid people in studying the GLEP. The GLEP workflow section allows
> for this. I'd say at least a standard emerge system should be working
> before this GLEP is approved.
The Glep is a ways off from being approved imo, since still have a 
fair amount of ramnifications to nail down.  Ciaranm's home request is 
valid, so that bit should at least be nailed down requirements wise, 
before proceeding... 

Re: implementation, the bug referenced on the glep actually holds 
patches in already in use by haubi.  Would be good to bundle it up 
into a tarball (imo) for easier testing however...
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]

On Fri, 6 May 2005 20:05:18 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| On Fri, May 06, 2005 at 02:28:49PM +0100, Ciaran McCreesh wrote:
| > The problem isn't the packages. The problem is the ebuilds.
| Agreed, although seemed to take a bit of dancing to get done to the 
| fact that yes, changing the prefix has a good chance of working.
| 
| From there, we're back to the old two step econf/eclasses _do_ address
| a sizable portion of ebuilds in the tree ;)

More to the point, they *don't* address a sizable portion of the ebuilds
in the tree.

| Not much for a keyword route personally, since (imo) it's a slight 
| perversion of the focus of keywords.  If the keywording route was 
| taken, would need to either duplicate existing keywords (have 
| x86/~x86, and x86-weirdo-prefix ~x86-weirdo-prefix), or require two 
| specific keywords being set (x86 and weirdo-prefix from the example 
| above).  
| 
| I'd suspect your metadata addition (which needs a better name then 
| ICANINSTALLTO) is the best route.

That was what I was proposing. Not KEYWORDS, a new variable. Which needs
a better name than ICANINSTALLTO.

| > | So, fink demonstration of --prefix hackery?
| > 
| > If you want a better example, try either SGI or Sun's GNU tools
| > ports. But they don't use ebuilds either.
| Well, main point was that the underlying packages _can_ swing this 
| type of hackery for the most part, what is needed is a tweak to our 
| ebuild conventions to allow for it.

'tweak' is too mild a term... As far as I can tell I'm the only person
who's bothered to actually even try to look at this from an ebuild
perspective -- not pretty... For every package in the tree that has a
sed -e 's,/usr/local,/usr,g' there's another that would need a sed
turning /usr into whatever prefix ends up as, and it's not at all
obvious what they are. It gets even worse when you consider all the
stuff with #!/usr/bin/blah hardcoded that will need changed to use our
interpreter prefix -- these are very tricky to spot if you have a
braindead vendor-supplied interpreter in /usr/bin too.

Sure, it can be done, but not all at once, hence me screaming whitelist.

| Meanwhile, iirc from the last irc conversation on this, either you or 
| dsd brought up the point of needing to be able to query if (using vim 
| as an example) vim-core was $home, rather then usr|$PREFIX.  Care to 
| elaborate a bit?  Mainly wondering if to encompass your requests, it 
| might require extra metadata from the depend standpoint.

Ok, say we use ICANINSTALLTO (name!). Then if we have "prefix" as the
destination, there's no problem, because we know that all our deps are
installed in ${PREFIX} as well. However, if we're installing to "home",
we need to know where our deps are -- for "home" installs I'm presuming
we don't force a full dep tree in "home" (unlike for "prefix"). This
*could* still be done with ${PREFIX} I guess? Or to avoid confusing
things, ${DEPS_PREFIX}? Not really sure...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

On Sat, May 07, 2005 at 02:39:20AM +0100, Ciaran McCreesh wrote:
> 'tweak' is too mild a term... As far as I can tell I'm the only person
> who's bothered to actually even try to look at this from an ebuild
> perspective

Surprisingly, not quite true (was fun stating it I'm sure though).


> -- not pretty... For every package in the tree that has a
> sed -e 's,/usr/local,/usr,g' there's another that would need a sed
> turning /usr into whatever prefix ends up as

Dodging the valid sed criticism, no, a secondary sed would be 
something of a hack.  Substitue the prefix var instead.

Re: changes, yes, things will need changes, and again, as stated 
thrice, those who want the changes are the ones who are stuck doing 
said changes.  In other words, the actual work required to 
cleanse/correct the tree isn't getting dumped on ebuild devs as a whole.  

The change in conventions for writing ebuilds _is_ falling on 
ebuild dev's heads.  

Remember that in the grand scheme of things, the required changes to how 
ebuilds are written is a helluva lot more important then basically 
retrofitting existing ebuilds.

In other words, you would be wise to snipe the suggested changes to 
writing an ebuild, rather then dragging out example after example of 
possible required changes to the tree.  The examples you're dragging 
out basically come down to making sure the ebuild is 'correct' for the 
package.  I can just as quickly drag out example after example of 
potential mistakes ebuild devs can make _now_.

Basically, if the only thing you can point out as a con against this 
glep is changes -the interested parties would have to make to the 
existing tree-, please summarize rather then dragging this out over a 
week.  If you're after arguing that the potential complexity involved 
in mapping an ebuild into a nonstandard prefix is too large, summarize 
and state that, etc.

Getting a bit tired of repeatedly stating (whether irc or ml) "yes, 
the existing tree would require modification, and yes, you don't have 
to do the heavy lifting, those interested do".

If this portion of the discussion is to continue, please split 
it off into a seperate thread, thus far it's hijacked the discussion 
and is more centered on crappy ebuilds/packages, rather then potential 
changes.  Not saying it's not a valid point, just saying "yeah, you 
got your point across, now can we move on to the other portions that 
need discussion?".  Remember that gleps go through several rounds of 
discussion, I'd like to see this round keep moving rather then get 
stuck in the mud.


> | Meanwhile, iirc from the last irc conversation on this, either you or 
> | dsd brought up the point of needing to be able to query if (using vim 
> | as an example) vim-core was $home, rather then usr|$PREFIX.  Care to 
> | elaborate a bit?  Mainly wondering if to encompass your requests, it 
> | might require extra metadata from the depend standpoint.
> 
> Ok, say we use ICANINSTALLTO (name!). Then if we have "prefix" as the
> destination, there's no problem, because we know that all our deps are
> installed in ${PREFIX} as well. However, if we're installing to "home",
> we need to know where our deps are -- for "home" installs I'm presuming
> we don't force a full dep tree in "home" (unlike for "prefix"). This
> *could* still be done with ${PREFIX} I guess? Or to avoid confusing
> things, ${DEPS_PREFIX}? Not really sure...

Could you break it down to "if I'm going into home, I need xyz at the 
home level rather then global/usr" ?
as in something along the lines of 
if dep_installation_target some-vim-dep home; then
	# do the home equiv
else
	# do the global equiv
fi;

?
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

Ciaran McCreesh wrote:
> Ok, say we use ICANINSTALLTO (name!). Then if we have "prefix" as the
> destination, there's no problem, because we know that all our deps are
> installed in ${PREFIX} as well. However, if we're installing to "home",
> we need to know where our deps are -- for "home" installs I'm presuming
> we don't force a full dep tree in "home" (unlike for "prefix"). This
> *could* still be done with ${PREFIX} I guess? Or to avoid confusing
> things, ${DEPS_PREFIX}? Not really sure...

As for the new metadata variable, I think it should be a complement to 
RESTRICT (not limited to prefix). As the name for this var I suggest 
SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME 
it would look like:
SUPPORTS="prefix prefix-home" (as /usr is implicit)

Marius
-- 
gentoo-dev@gentoo.org mailing list

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

[Michael Haubenwallner]

Packages installing into '/' can install into "/${AFFIX}" then, and when
there are softlinks to be done from /usr/bin/ to /bin/, they need to be done
if [ "/${AFFIX}" != "${PREFIX}/" ] or if [ -z "${AFFIX}" ].

----- Original Message -----
From: "Jason Stubbs" <jstubbs@gentoo.org>
To: <gentoo-dev@lists.gentoo.org>
Sent: Tuesday, May 03, 2005 3:22 PM
Subject: Re: [gentoo-dev] new glep draft: Portage as a secondary package
manager

On Monday 02 May 2005 21:22, Michael Haubenwallner wrote:
> Hi ebuild devs,
>
> Here's a glep draft now for (a part of) the long-term portage-goal
> "act as a secondary package manager" ...

How about packages that usually install into "/"?

Regards,
Jason Stubbs



-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

On Sat, 7 May 2005 02:08:17 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| Re: changes, yes, things will need changes, and again, as stated 
| thrice, those who want the changes are the ones who are stuck doing 
| said changes.  In other words, the actual work required to 
| cleanse/correct the tree isn't getting dumped on ebuild devs as a
| whole.  

Isn't going to work. A lot of these changes need package-specific
knowledge that most people just don't have.

| In other words, you would be wise to snipe the suggested changes to 
| writing an ebuild, rather then dragging out example after example of 
| possible required changes to the tree.  The examples you're dragging 
| out basically come down to making sure the ebuild is 'correct' for the
| package.  I can just as quickly drag out example after example of 
| potential mistakes ebuild devs can make _now_.

No, they're a demonstration of why the GLEP in its current form is
inadequate. I'll carry on pulling up further examples until you realise
that it's not just a minor issue, it's a huge problem that needs a big
change to the GLEP.

| Remember that gleps go through several rounds of 
| discussion, I'd like to see this round keep moving rather then get 
| stuck in the mud.

The reason that this thing was written up as a GLEP was because the
author was trying to bypass the discussion and get around having to fix
various flaws that had been pointed out previously.

| Could you break it down to "if I'm going into home, I need xyz at the 
| home level rather then global/usr" ?

Hrm. Being able to say "I need xyz installed globally, and abc installed
either globally or at home level" would work if and only if there was a
way of finding out where abc and xyz had been installed.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Kito]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 7, 2005, at 9:49 AM, Ciaran McCreesh wrote:

> On Sat, 7 May 2005 02:08:17 -0500 Brian Harring <ferringb@gentoo.org>
> wrote:
> | Re: changes, yes, things will need changes, and again, as stated
> | thrice, those who want the changes are the ones who are stuck doing
> | said changes.  In other words, the actual work required to
> | cleanse/correct the tree isn't getting dumped on ebuild devs as a
> | whole.
>
> Isn't going to work. A lot of these changes need package-specific
> knowledge that most people just don't have.

If a dev doesn't have adequate knowledge for a particular package he 
shouldn't be fscking with it in the first place. So there said package 
can sit, having only the ability to install to / just like it always 
has until someone with interest/need/knowledge comes along and takes 
care of it.

All the points you are making sound like the result of too much crisis 
management, progress shouldn't be impeded by fear of work or change.

>
> | In other words, you would be wise to snipe the suggested changes to
> | writing an ebuild, rather then dragging out example after example of
> | possible required changes to the tree.  The examples you're dragging
> | out basically come down to making sure the ebuild is 'correct' for 
> the
> | package.  I can just as quickly drag out example after example of
> | potential mistakes ebuild devs can make _now_.
>
> No, they're a demonstration of why the GLEP in its current form is
> inadequate. I'll carry on pulling up further examples until you realise
> that it's not just a minor issue, it's a huge problem that needs a big
> change to the GLEP.

How about suggesting what that big change would be?

>
> | Remember that gleps go through several rounds of
> | discussion, I'd like to see this round keep moving rather then get
> | stuck in the mud.
>
> The reason that this thing was written up as a GLEP was because the
> author was trying to bypass the discussion and get around having to fix
> various flaws that had been pointed out previously.
>
> | Could you break it down to "if I'm going into home, I need xyz at the
> | home level rather then global/usr" ?
>
> Hrm. Being able to say "I need xyz installed globally, and abc 
> installed
> either globally or at home level" would work if and only if there was a
> way of finding out where abc and xyz had been installed.

Hmmm, what about a possible extension to the world file or a create a 
new file to store metadata such as the package installation prefix.

Kito
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iD8DBQFCfN9mJ0rMK/3OwgsRAkQ4AJsFdsnck7jScHUDjarT3zO/+f0aCgCdGxyR
O8+F1FVJNGQSAO5peV9/qhk=
=4kQf
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

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

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

On Saturday 07 May 2005 23:49, Ciaran McCreesh wrote:
> Hrm. Being able to say "I need xyz installed globally, and abc installed
> either globally or at home level" would work if and only if there was a
> way of finding out where abc and xyz had been installed.

The "being able to say" is the harder part. ;)

Having a package find out where it's dependencies are is quite simple. 
Enhancing portageq to support it will be one of the smaller tasks in all of 
this. Wrapping that with a dev-friendly bash function will be even easier.

So to summarise prefixed install support thus far:

1  Portage needs to be enhanced with a new SUPPORTS so that packages can
   specify that they can install into a non-standard location.
2  Portage needs to be enhanced with new ebuild support functions for
   detecting the location of a dependency.
3  Portage needs to supply PREFIX and AFFIX variables to those ebuilds that
   support non-standard location installs, which specify executable and
   configuration/data locations respectively.
4  Portage needs a base PREFIX and AFFIX to install to by default.
5  Packages need to be updated for support of these feature.
   - Packages that have a standard location of / rather than /usr install into
     AFFIX rather than PREFIX.

And to add my own little pieces of wisdom:

6  Portage must disallow the creation of binary packages where all
   dependencies are not in the same PREFIX.
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.

I was planning to summarize home install support here, but your statement 
above has confused me a little. Is there any case where a package *must* have 
a dependency installed globally? If so, I can't see it.

So unless it is shown otherwise, home install support requires:

8  SUPPORTS needs to be enhanced with another indicator for packages to 
   specify that they can do home installs.
9  Emerge needs to be enhanced to allow the user to specify if they want a
   home install or a prefixed install of a package.
10 Portage needs to tell the ebuild whether it should perform a home install 
   or a prefixed install.

Does that about cover it?

Regards,
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

On Sat, 7 May 2005 10:31:49 -0500 Kito <kito@gentoo.org> wrote:
| > Isn't going to work. A lot of these changes need package-specific
| > knowledge that most people just don't have.
| 
| If a dev doesn't have adequate knowledge for a particular package he 
| shouldn't be fscking with it in the first place. So there said package
| can sit, having only the ability to install to / just like it always 
| has until someone with interest/need/knowledge comes along and takes 
| care of it.

You and I know that. Brian seems to be assuming that the people that do
the work will know how to handle every single package in the tree.

| All the points you are making sound like the result of too much crisis
| management, progress shouldn't be impeded by fear of work or change.

Eh? No. It's about getting a major change done cleanly and without
causing another disaster of OSX-sized proportions.

| > No, they're a demonstration of why the GLEP in its current form is
| > inadequate. I'll carry on pulling up further examples until you
| > realise that it's not just a minor issue, it's a huge problem that
| > needs a big change to the GLEP.
| 
| How about suggesting what that big change would be?

I've done that already several times in this thread.

| > The reason that this thing was written up as a GLEP was because the
| > author was trying to bypass the discussion and get around having to
| > fix various flaws that had been pointed out previously.
| >
| > | Could you break it down to "if I'm going into home, I need xyz at
| > | the home level rather then global/usr" ?
| >
| > Hrm. Being able to say "I need xyz installed globally, and abc 
| > installed
| > either globally or at home level" would work if and only if there
| > was a way of finding out where abc and xyz had been installed.
| 
| Hmmm, what about a possible extension to the world file or a create a 
| new file to store metadata such as the package installation prefix.

Needs to be easily accessible from the ebuild. Parsing things in bash is
a nuisance.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Sun, 8 May 2005 00:47:05 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| I was planning to summarize home install support here, but your
| statement  above has confused me a little. Is there any case where a
| package *must* have  a dependency installed globally? If so, I can't
| see it.

I'm kinda inclined to say that there will be situations in which
packages must have a dependency installed in either / or prefix, *not*
homedir. But then, I can't think of a situation where all of the
following would be true:

* A package requires a (/ or prefix) install of a dep
* The dep in question is capable of being installed into homedir

So I think your list is good.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

On Sat, May 07, 2005 at 04:51:36PM +0100, Ciaran McCreesh wrote:
> | If a dev doesn't have adequate knowledge for a particular package he 
> | shouldn't be fscking with it in the first place. So there said package
> | can sit, having only the ability to install to / just like it always 
> | has until someone with interest/need/knowledge comes along and takes 
> | care of it.
> 
> You and I know that. Brian seems to be assuming that the people that do
> the work will know how to handle every single package in the tree.

You're agreeing to the point kito made (my point spelled out for you) 
and you take a parting shot at me?

Was that really needed?


> Eh? No. It's about getting a major change done cleanly and without
> causing another disaster of OSX-sized proportions.

Fud.

OSX was a disaster _because_ it was implemented and dumped on everyone else, 
without involving anyone else.  This discussion/glep is to hash out the 
idea and issues, _rather_ then making it official and dumping the 
issues on others to address.


> | > No, they're a demonstration of why the GLEP in its current form is
> | > inadequate. I'll carry on pulling up further examples until you
> | > realise that it's not just a minor issue, it's a huge problem that
> | > needs a big change to the GLEP.
> | 
> | How about suggesting what that big change would be?
> 
> I've done that already several times in this thread.

You've suggested ICANINSTALLTO, which has become SUPPORTS.  Beyond 
that you've either insulted those involved (the initial IRC 
discussion), or resorted to heckling the proposal via the same angle 
repeatedly.  Funny part is above you agree on the response I've 
stated to you repeatedly, only after it's written by someone else.


Intermixing another lovely bit of your slander/attacks.
> The reason that this thing was written up as a GLEP was because the                                                                           
> author was trying to bypass the discussion and get around having to 
> fix various flaws that had been pointed out previously.

I suggested haubi write it up as a glep, and bring it to this ml for 
the purpose of discussion of it, issues and all.

The funny thing is, if we just slipped the changes into portage and 
released it, we would be sidestepping the issues.  It would be the OSX 
disaster.

Write the sucker up as a glep, issues and all for discussion, and you 
attack those involved as "trying to bypass the discussion".

So pretty much it's screwed if you do, screwed if you don't.  That's 
definitely one way to block progress on it; even bringing up the idea
equals you flaming/attacking those involved with it.

The entertaining aspect of this whole exchange is that you agree to 
jason's rephrasing of it (plus binpkg issues), which is the same damn 
thing you've been arguing against.

Basically, you've been an ass for the sake of being an ass thus far 
for anyone involved in the proposal.
It's not needed, and just wasted a chunk of my time, and yours for no 
valid reason.
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

On Sun, May 08, 2005 at 12:47:05AM +0900, Jason Stubbs wrote:
> 6  Portage must disallow the creation of binary packages where all
>    dependencies are not in the same PREFIX.
First level, second level... ?
I'd rather see the deps/prefix data slapped into the binpkg, and 
tracked alongside, and verified prior to installation.
Reason being- say a package links against libssl, and 
is built to be installed into a user's directory (irssi for example).  
A restriction of the sort you're specifying would block irssi from 
ever being binpkg'd for home installation.

> I was planning to summarize home install support here,
Clarify please :)
Offhand, I don't see why a bin repo for a home target isn't viable, 
along with a vdb repo in the same location.  It's a bit trickier, but 
I suspect it might be a bit more flexible in the long run.
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On Sun, 8 May 2005 02:58:32 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| Write the sucker up as a glep, issues and all for discussion, and you 
| attack those involved as "trying to bypass the discussion".

Bah. It should have been written up as a GLEP with the initial feedback
already incorporated.

| The entertaining aspect of this whole exchange is that you agree to 
| jason's rephrasing of it (plus binpkg issues), which is the same damn 
| thing you've been arguing against.

I'm not arguing against the general concept. I'm arguing against some of
the implementation issues which you and Michael are trying to gloss
over. You know this, stop trying to spin it any other way.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Marius Mauch]

Brian Harring wrote:
> Clarify please :)
> Offhand, I don't see why a bin repo for a home target isn't viable, 
> along with a vdb repo in the same location.  It's a bit trickier, but 
> I suspect it might be a bit more flexible in the long run.

I don't think that's possible without a lot of hacking for many packages 
as $HOME will be expanded at build time and might be included in the 
resulting binaries. Or in other words: If it works, we don't need 
$PREFIX support at all as packages could be relocated at merge time.

Marius
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

On Mon, May 09, 2005 at 03:46:57AM +0300, Marius Mauch wrote:
> Brian Harring wrote:
> >Clarify please :)
> >Offhand, I don't see why a bin repo for a home target isn't viable, 
> >along with a vdb repo in the same location.  It's a bit trickier, but 
> >I suspect it might be a bit more flexible in the long run.
> 
> I don't think that's possible without a lot of hacking for many packages 
> as $HOME will be expanded at build time and might be included in the 
> resulting binaries. Or in other words: If it works, we don't need 
> $PREFIX support at all as packages could be relocated at merge time.
Was referencing per home binrepo's; basically (if desired by the 
admin/user), binpkg backups of per user home targets.

End result is per user FEATURES="buildpkg" support, with the binpkgs 
safely tucked away within $HOME of the user.  If we're already doing 
the dep calculation of what nodes are needed, and where (home prefix, 
or global, etc), don't see why that info can't be tucked away and used 
as a restriction for the binpkg generated for that particular user...
~brian
-- 
gentoo-dev@gentoo.org mailing list

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

[Michael Haubenwallner]

----- Original Message -----
From: "Marius Mauch" <genone@gentoo.org>
> Ciaran McCreesh wrote:
<snip>
> As for the new metadata variable, I think it should be a complement to
> RESTRICT (not limited to prefix). As the name for this var I suggest
> SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME
> it would look like:
> SUPPORTS="prefix prefix-home" (as /usr is implicit)

For the values of the SUPPORTS-Variable (i like the name) i'd prefer some
words pointing to the package-manager used (primary/secondary/home), fex
"secondarypm homepm" or "2ndpm homepm" or the like (more ideas welcome),
because /usr is a 'prefix' too.

But here's just one point to think of how to avoid redundant information in
ebuilds:

The SUPPORTS-Variable _will_ be necessary for home-installation, sure. But
when an ebuild has KEYWORDS='sparc' and SUPPORTS='2ndpm', this does not
automatically imply that it compiles on a 'sparc-solaris' - this keyword has
to be added explicitly.

But how likely is it that on 'sparc-solaris' portage would be the primary
pkg mgr installing into /usr ?

So when an ebuild has 'sparc-solaris' in keywords, imo one can assume that
it _does_ support "secondarypm" (also look at
http://www.gentoo.org/proj/en/glep/glep-0022.html#reasonable-defaults).

Or is this assumption too much implicit ?

Well, right, this will break the bsd keyworded ebuilds when used with a
secondary pm unless they support it, so this would not be a reasonable way
to go, just a point to think of (imo installing into primary prefix with a
secondary pkg mgr is sth. weird...)

~haubi

PS: sorry for beeing offline most of the time, i'm on holiday until May 17,
just sporadically reading mail, and completely offline from May 13


-- 
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

Michael Haubenwallner wrote:
> ----- Original Message -----
> From: "Marius Mauch" <genone@gentoo.org>
> 
>>Ciaran McCreesh wrote:
> 
> <snip>
> 
>>As for the new metadata variable, I think it should be a complement to
>>RESTRICT (not limited to prefix). As the name for this var I suggest
>>SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME
>>it would look like:
>>SUPPORTS="prefix prefix-home" (as /usr is implicit)
> 
> 
> For the values of the SUPPORTS-Variable (i like the name) i'd prefer some
> words pointing to the package-manager used (primary/secondary/home), fex
> "secondarypm homepm" or "2ndpm homepm" or the like (more ideas welcome),
> because /usr is a 'prefix' too.

That looks horribly confusing. Doesn't really matter if /usr is a prefix 
or not.

> But here's just one point to think of how to avoid redundant information in
> ebuilds:
> 
> The SUPPORTS-Variable _will_ be necessary for home-installation, sure. But
> when an ebuild has KEYWORDS='sparc' and SUPPORTS='2ndpm', this does not
> automatically imply that it compiles on a 'sparc-solaris' - this keyword has
> to be added explicitly.
> 
> But how likely is it that on 'sparc-solaris' portage would be the primary
> pkg mgr installing into /usr ?

Depends if there will be a Gentoo/OpenSolaris ...

> So when an ebuild has 'sparc-solaris' in keywords, imo one can assume that
> it _does_ support "secondarypm" (also look at
> http://www.gentoo.org/proj/en/glep/glep-0022.html#reasonable-defaults).
> 
> Or is this assumption too much implicit ?

It would be confusing IMO.

Marius
-- 
gentoo-dev@gentoo.org mailing list

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

[Michael Haubenwallner]

Jason Stubbs wrote:
> So to summarise prefixed install support thus far:
<snip>
> 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) ?

For the former, `portageq` or even ${PREFIX} should work,
for the latter, why are package.provides (aka injections) insufficient ?

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.

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

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

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

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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Thu, 19 May 2005 10:18:03 +0200 Michael Haubenwallner
<michael.haubenwallner@salomon.at> wrote:
| > 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.

Naah. Not really. The hard part is figuring out how to correctly change
all shell scripts that start with #!/bin/sh to use the portage-provided
sh instead, all perl scripts that start with #!/usr/bin/perl or
#!/usr/bin/env perl to use the portage-provided perl instead, how to fix
all autotools checks which look in /usr/lib first and so on. From an
ebuild perspective, which is where most of the work will be, asking
portage just where it *should* look is really just a sidenote that needs
to be documented somewhere.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Michael Haubenwallner]

Ciaran McCreesh wrote:
> On Thu, 19 May 2005 10:18:03 +0200 Michael Haubenwallner
> | But imo the home-support _really_ requires another glep, as there
> | are lots of more issuses than for the prefix-support.
> 
> Naah. Not really. The hard part is figuring out how to correctly change
> all shell scripts that start with #!/bin/sh to use the portage-provided
> sh instead, all perl scripts that start with #!/usr/bin/perl or
> #!/usr/bin/env perl to use the portage-provided perl instead, how to fix
> all autotools checks which look in /usr/lib first and so on. From an
> ebuild perspective, which is where most of the work will be, asking
> portage just where it *should* look is really just a sidenote that needs
> to be documented somewhere.
> 

Here some things imo not needed to mention in the glep:

Most of the packages (not ebuilds) wont work on systems without
/bin/sh (Bourne-Shell, not bash) and /usr/bin/env, so there's no need to
have a Bourne-Shell installed in /my/prefix/bin/sh instead of /bin/sh.

When a user wants to use things (including portage) from /my/prefix,
he/she has to source /my/prefix/etc/profile (this could be in the glep).

Once this is done, this line will find the portage-installed
interpreters:
#! /usr/bin/env {bash,perl,python,whatever}

When portage starts the ebuild-daemon, i've seen that portage removes
PATH from environment and lets bash use its default-PATH.

So i've added one more patch to bash.ebuild to change the default-PATH
to "/my/prefix/bin:/usr/bin:/bin" if prefix!=/usr instead of
"/usr/local/bin:/usr/bin:/bin", which is done in bash.ebuild right now.

autoconf-checks: i configure gcc '--with-local-prefix=/my/prefix' in
case of prefix!=/usr, so gcc searches in "/my/prefix/lib:/usr/lib:/lib"
for libraries by default, and the checks should rely on the compiler to
find the right libraries when configuring.

Another one is ld.so.conf:
All of the shlib-loaders know some kind of LD_LIBRARY_PATH in environ,
and instead of writing /my/prefix/etc/ld.so.conf, portage puts the
LDPATH-bits from env.d/ into this variable, so finding the right
shared-libs does work.

So at least bash is required to be installed into same prefix as
portage, and its easier to have gcc here too instead of setting
CPATH and LIBRARY_PATH to /my/prefix/{include,lib} and providing gcc.

And it is necessary to have different baselayouts and profiles necessary
for different systems (solaris,aix,hpux,...) to keep the differences
outside of portage.

And for a package (not the ebuild) which cannot install to prefix, it is
unlikely that it makes sense to install it besides the primary prefix.

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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Thu, 19 May 2005 13:05:20 +0200 Michael Haubenwallner
<michael.haubenwallner@salomon.at> wrote:
| Most of the packages (not ebuilds) wont work on systems without
| /bin/sh (Bourne-Shell, not bash) and /usr/bin/env, so there's no need
| to have a Bourne-Shell installed in /my/prefix/bin/sh instead of
| /bin/sh.

So what if /bin/sh is a nastily h0rked non-POSIX implementation? Or what
if we have packages with a dep upon a specific sh version? The portage
provided version must be used in all cases.

| Once this is done, this line will find the portage-installed
| interpreters:
| #! /usr/bin/env {bash,perl,python,whatever}

No good, because we won't be using the portage-provided env binary. And
that only works for things that actually use env (which is considered
discouraged).

| autoconf-checks: i configure gcc '--with-local-prefix=/my/prefix' in
| case of prefix!=/usr, so gcc searches in
| "/my/prefix/lib:/usr/lib:/lib" for libraries by default, and the
| checks should rely on the compiler to find the right libraries when
| configuring.

I could dig out a rather large list of annoying counterexamples, all of
which would need manual fixing...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Michael Haubenwallner]

One general Question:
How can open source packages work on Unices which are non-Gentoo-Linux
if there are that many unresolved issues you try to point out ?

This is what autoconf and libtool are for, and if a package lacks using
them, autoconf/libtool-like trickery has to be done in ebuilds.

There are always 'what if' situations, where the secondary package
manager cannot be responsible for. Portage and ebuilds have to avoid
_all_ those situations _only_ if portage is the _primary_ pkg mgr.

As secondary pkg mgr, _some_ basic working things must be presumeable.

Ciaran McCreesh wrote:
> On Thu, 19 May 2005 13:05:20 +0200 Michael Haubenwallner
> <michael.haubenwallner@salomon.at> wrote:
> | Most of the packages (not ebuilds) wont work on systems without
> | /bin/sh (Bourne-Shell, not bash) and /usr/bin/env, so there's no need
> | to have a Bourne-Shell installed in /my/prefix/bin/sh instead of
> | /bin/sh.
> 
> So what if /bin/sh is a nastily h0rked non-POSIX implementation? Or what
> if we have packages with a dep upon a specific sh version? The portage
> provided version must be used in all cases.

If /bin/sh is a bad shell, many packages wouldn't work,
independend if installed by hand or by portage/ebuilds.

And if a package depends on specific version, it is able to find such a
version itself or at least to specify the location of the right version.

> | Once this is done, this line will find the portage-installed
> | interpreters:
> | #! /usr/bin/env {bash,perl,python,whatever}
> 
> No good, because we won't be using the portage-provided env binary. And
> that only works for things that actually use env (which is considered
> discouraged).

Same here, if a package cannot operate with /usr/bin/env on
non-Gentoo-Linuxes, and is dedicated to run on such Unices,
it should be able to find the right one or get it specified.

No somewhat correct package, which says to run on Unix, should have
hardcoded '#! /usr/bin/perl' but find it in PATH.

> | autoconf-checks: i configure gcc '--with-local-prefix=/my/prefix' in
> | case of prefix!=/usr, so gcc searches in
> | "/my/prefix/lib:/usr/lib:/lib" for libraries by default, and the
> | checks should rely on the compiler to find the right libraries when
> | configuring.
> 
> I could dig out a rather large list of annoying counterexamples, all of
> which would need manual fixing...
> 

Sure, but what's the problem with manual fixing ?
The one who needs it will look for how to fix it.

And why not let portage support features not required for Gentoo-Linux ?

Portage is just another open source package, which is able to be ported
to other Unices, with the power to become _the_ secondary pkg mgr.

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

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

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 3647 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

On Thu, 19 May 2005 14:46:34 +0200 Michael Haubenwallner
<michael.haubenwallner@salomon.at> wrote:
| How can open source packages work on Unices which are non-Gentoo-Linux
| if there are that many unresolved issues you try to point out ?

The issues I'm pointing out are things which are issues with the way
ebuilds are set up and the way builds are done in general. They're some
of the same issues that you'll encounter when doing ports to nasty unix
clones.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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@salomon.at  http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html
-- 
gentoo-dev@gentoo.org mailing list

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

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 10143 bytes --]

On Friday 20 May 2005 21:30, Michael Haubenwallner wrote:
> 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 ?

Any package that does this is broken. There are a couple of cases where 
there's no other choice because portage doesn't allow for anything else but 
that will change.

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

I would fiercely disagree with implementing ${PREFIX} support without doing 
major changes in portage to support it. There's enough hacks in portage 
already.

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

In general, I do not be the case.

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

+ Portage is able to know what a package requires and can ensure system
  consistency.

+ Binary packages are possible.

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

Wrong. What do you think *DEPEND is if it's not "autoconf alike intelligence"?

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

No different to the current system. This is what package.provided is for.

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

Such as? I don't know if this is a pro or a con or what.

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

Without it, there is no guarantee of system consistency and hence no reason 
for adding support for it into portage at all. If you don't want portage to
maintain system consistency for you, why not just do "./configure; make; make 
install" ?

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

Different behaviour between prefix or ~ only. / is just another prefix. This 
is definitely not a con of philosophy 1. It is a requirement regardless.

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

"necessary"? I think not.

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

Works the same for "/", no? Tell me again what the point of portage is?

> + This is what autoconf/libtool are created for.

Do you use a new point to reiterate your last point just to make it look like 
your way is better?

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

Woops. Exactly the same point again.

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

And again. Except that here you're saying that system consistency should be 
thrown out the window altogether. It seems to me like your concept of portage 
is:

emerge() {
	PKG="$1"
	tar zxf ${PKG}
	cd ${PKG/.tar.gz/}
	./configure
	make && make install
}

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

Again, why use portage at all?

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

Eh? Where did that come from?

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

Where do USE flags come into this?

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

This isn't a pro or con either. It's just a simple fact that exists 
regardless.

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

Wrong. Portage does predetermine which philosophy to use. With your option 2, 
there is no way to do:

1) A working version of depclean
2) Safe unmerging of packages
3) Binary packages
4) Parallel compiles (future goal)
5) Dispatched compiles in a portage cluster (future goal)

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

It really seems that Gentoo doesn't suit your way of thinking at all.

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

Building a dependency graph implies gaining the knowledge of where packages 
are or will be installed. Passing that information to ebuilds is a minor 
thing.

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

Forget this. It's an implementation detail but we're not even past concept let 
alone design.

> > 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 ~ ?

I haven't either. However, Ciaran posted about this. The main difference is 
that the directory structure changes completely.

> > 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 haven't worked with it either. I know that there's extensive 
cross-compilation support in the toolchain but I'm pretty sure there's little 
to none before that. Using portage for cross-compilation at the moment is a 
touch-and-go thing that requires a lot of hacking.

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

It's a huge amount of work to get full support into portage as well. However, 
most of it is working through the concepts involved and designing 
accordingly. The actual implementation differs little to what is required for 
the current system.

Regards,
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Michael Haubenwallner]

Jason Stubbs wrote:
> On Friday 20 May 2005 21:30, Michael Haubenwallner wrote:
<snip>
>>But - aren't there many settings left over to the packages to decide,
>>at least to choose the package-defaults ?
> 
> 
> Any package that does this is broken. There are a couple of cases where 
> there's no other choice because portage doesn't allow for anything else but 
> that will change.

Hmm - are there ideas/plans already around how that will change -
did i miss something ?

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

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

[Michael Haubenwallner]

Ok, no separate glep for home installation:

So i need some clues how to install plugins into home - attached is some
ebuild patch sample (actually not a diff output) how i would try to start
with vim-plugins.eclass, as a discussion base.

Variables to be set by portage:
PREFIX="/home/haubi"
AFFIX="home/haubi/" (not used here)
INSTALL_TARGET_TYPE="home" (value is found in the SUPPORTS
metadata-variable)
This is a new variable which needs a better name, or even a portage-function
for querying the install target type, which comes from the
'emerge --target home' bit by Brian Harring.

Is it confusing when PREFIX contains home-dirs - should another variable
name be used for home-dir, or should PREFIX/AFFIX be renamed - suggestions ?

Where should additional documents (seen in current vim-plugin_src_install)
go to ?
Can `id -un`:`id -gn` (maybe wrapped by some portage function, using glep 27
for non-home-target) be used to set the owner of the files ?

~haubi


begin 666 vim-plugins-home.patch
M("!V:6TM<&QU9VEN7W-R8U]I;G-T86QL*"D@>PHM(" @("!L;V-A;"!F"BL@
M(" @(&QO8V%L(&8@=7-E<B!G<F]U<"!D97-T8F%S92!D97-T9&ER"BL@"BL@
M(" @(&EF(%L@(B1[24Y35$%,3%]405)'151?5%E017TB(#T@(FAO;64B(%T*
M*R @(" @=&AE;@HK(" @(" @(" @(R!T:&ES(&ES(&YO="!G;&5P(#(W"BL@
M(" @(" @("!U<V5R/6!I9" M=6Y@"BL@(" @(" @("!G<F]U<#U@:60@+6=N
M8 HK(" @(" @(" @9&5S=&)A<V4](B1[4%)%1DE8?2(@(" C(%!2149)6#TO
M:&]M92\\=7-E<CX**R @(" @(" @(&1E<W1D:7(](BYV:6TB"BL@(" @(&5L
M<V4**R @(" @(" @(",@9VQE<" R-R!A<'!L:65S(&AE<F4@/PHK(" @(" @
M(" @=7-E<CUR;V]T"BL@(" @(" @("!G<F]U<#UR;V]T"BL@(" @(" @("!D
M97-T8F%S93TB)'M04D5&25A]+W-H87)E+W9I;2(**R @(" @(" @(&1E<W1D
M:7(](G9I;69I;&5S(@HK(" @("!F:0H*(" @(" @96)E9VEN(")&:7AI;F<@
M9FEL92!P97)M:7-S:6]N<R(*(" @(" @(R!-86ME('-U<F4@<&5R;7,@87)E
M(&=O;V0*(" @(" @8VAM;V0@+5(@82MR6" D>U-]('Q\(&1I92 B8VAM;V0@
M9F%I;&5D(@HM(" @("!F:6YD("1[4WT@+75S97(@("=P;W)T86=E)R M97AE
M8R!C:&]W;B!R;V]T("=[?2<@7#L@?'P@9&EE(")C:&]W;B!F86EL960B"BT@
M(" @(&9I;F0@)'M3?2 M9W)O=7 @)W!O<G1A9V4G("UE>&5C(&-H9W)P(')O
M;W0@)WM])R!<.R!\?"!D:64@(F-H9W)P(&9A:6QE9"(**R @(" @9FEN9" D
M>U-]("UU<V5R(" G<&]R=&%G92<@+65X96,@8VAO=VX@(B1[=7-E<GTB("=[
M?2<@7#L@?'P@9&EE(")C:&]W;B!F86EL960B"BL@(" @(&9I;F0@)'M3?2 M
M9W)O=7 @)W!O<G1A9V4G("UE>&5C(&-H9W)P("(D>V=R;W5P?2(@)WM])R!<
M.R!\?"!D:64@(F-H9W)P(&9A:6QE9"(*(" @(" @965N9" D/PH**'-N:7!P
M960@=&AE(&1O8W5M96YT871I;VXI"@HM(" @("!D;V1I<B O=7-R+W-H87)E
M+W9I;0HM(" @("!M=B D>U-]("1[1'TO=7-R+W-H87)E+W9I;2]V:6UF:6QE
M<PHK(" @("!D;V1I<B B)'MD97-T8F%S97TB"BL@(" @(&UV("1[4WT@(B1[
?1'TD>V1E<W1B87-E?2\D>V1E<W1D:7)](@H@('T*"@``
`
end

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Tue, 24 May 2005 11:53:30 +0200 "Michael Haubenwallner"
<michael.haubenwallner@salomon.at> wrote:
| Variables to be set by portage:
| PREFIX="/home/haubi"
| AFFIX="home/haubi/" (not used here)

Hrm. So what do we use for finding out where our non-home deps are
installed then?

| Where should additional documents (seen in current
| vim-plugin_src_install) go to ?

I'd suggest that you try something like gkrellm plugins -- there're some
nice subtleties with vim plugins to do with docs tag generation that
will require patching vim itself for things to work properly.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Tue, May 24, 2005 at 11:07:54AM +0100, Ciaran McCreesh wrote:
> On Tue, 24 May 2005 11:53:30 +0200 "Michael Haubenwallner"
> <michael.haubenwallner@salomon.at> wrote:
> | Variables to be set by portage:
> | PREFIX="/home/haubi"
> | AFFIX="home/haubi/" (not used here)
> 
> Hrm. So what do we use for finding out where our non-home deps are
> installed then?
add a bash func that abuses the ebd pipes to query 
portage directly.  
get_installed_prefix ${atom} might fly, although naming/ironing out 
semantics is required.
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Michael Haubenwallner]

Argh, yes, sure (should always make proof of concept :).

So there's another new variable needed to contain "/home/haubi".
Could HOME be used (this currently points to the portage-defined empty
homedir) ?

My suggestions if not: IHOME, INSTALL_HOME, HOMEDIR, TARGETDIR, HOMETARGET,
...

~haubi

----- Original Message -----
From: "Ciaran McCreesh" <ciaranm@gentoo.org>
<michael.haubenwallner@salomon.at> wrote:
| Variables to be set by portage:
| PREFIX="/home/haubi"
| AFFIX="home/haubi/" (not used here)

Hrm. So what do we use for finding out where our non-home deps are
installed then?



-- 
gentoo-dev@gentoo.org mailing list