I'm interested in running Prefix on a Gentoo host, and I wanted to use
the Portage tree from the host instead of installing a duplicate.
This seems reasonable, but bootstrapping fails with:

$ ./bootstrap-prefix.sh "$EPREFIX" portage
…
* setting up some guessed defaults
* Your profile is set to /…/usr/portage/profiles/prefix/linux/amd64.
./bootstrap-prefix.sh: line 368: /…/usr/portage/profiles/prefix/linux/amd64/make.defaults: Permission denied
./bootstrap-prefix.sh: line 369: /…/usr/portage/profiles/prefix/linux/amd64/make.defaults: Permission denied
…
* Your make.globals is prepared for your current bootstrap
./bootstrap-prefix.sh: line 387: /…/usr/portage/profiles/pre* Your make.globals is prepared for your current bootstrap
./bootstrap-prefix.sh: line 387: /…/usr/portage/profiles/prefix/profile.bashrc: Permission denied
./bootstrap-prefix.sh: line 391: /…/usr/portage/profiles/prefix/package.provided: Permission denied
* prefix-portage successfully bootstrapped

Some thoughts:

* The failing commands should probably be `|| die …`, since
`prefix-portage successfully bootstrapped` is probably not true.

* Couldn't these profile overrides happen in
"${EPREFIX}/etc/portage/profile" (see portage(5))?

* How does Prefix currently detect and handle profile changes due to
rsync updates? Using “${EPREFIX}/etc/portage/profile� would seem to
be a good way to avoid getting clobbered.

Taking a longer view in this direction, it would be nice to see an
interface that allowed lighter weight prefixes, along the lines of
Python's `pip install --user …`. This would leave the user exposed to
updates in the host system breaking some of their prefixed packages,
but it would make setting up a prefix a lot faster if you just wanted
to install one extra package. Also, `revdep-rebuild` should be able
to find and fix those breakages automatically.

I suppose the problem is not “how would maintenance work?�, but
figuring out how to build such a chimeric system in the first place.
Portage would have to read from overlayed `/var/db/pkg` instances, and
then adjust include and linker flags on the fly. Can someone with
more experience in this area give me a quick “that's crazy because …�,
so it will stop bothering me?

Thanks,
Trevor

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

On 23-07-2012 13:32:47 -0400, W. Trevor King wrote:
> I'm interested in running Prefix on a Gentoo host, and I wanted to use
> the Portage tree from the host instead of installing a duplicate.
> This seems reasonable, but bootstrapping fails with:

The tree is different, so while it sounds reasonable, in reality it is
not. Sorry.


--
Fabian Groffen
Gentoo on a different level

23.07.2012, 21:32, "W. Trevor King" <wking@tremily.us>:
> I'm interested in running Prefix on a Gentoo host, and I wanted to use
> the Portage tree from the host instead of installing a duplicate.

You cannot use host Portage tree because Prefix tree is significantly
modified. You might be able to use Prefix tree for host though.

--
Regards,
Konstantin

On Mon, Jul 23, 2012 at 12:32 PM, W. Trevor King <wking@tremily.us> wrote:
> I'm interested in running Prefix on a Gentoo host, and I wanted to use
> the Portage tree from the host instead of installing a duplicate.
> This seems reasonable, but bootstrapping fails with:

It is a different tree, you can't share it with Gentoo Linux.

It is also worthwhile to note that the bootstrapping process WRITES to
the tree location, thus your permission denied errors.

-Jeremy

On Mon, Jul 23, 2012 at 08:07:57PM +0200, Fabian Groffen wrote:
> The tree is different, so while it sounds reasonable, in reality it is
> not. Sorry.

Ah, thanks for pointing that out. For some reason I thought that after

On Sun, Apr 1, 2012 at 16:59:53 +0200, Fabian Groffen wrote:
> The (good) news for users is that all packages from regular Gentoo
> are now also available for Prefix albeit being masked by missing
> keywords.

It makes sense that the trees will be different until the EPREFIX
stuff gets pulled into the main tree though.

On Mon, Jul 23, 2012 at 01:11:50PM -0500, Jeremy Olexa wrote:
> It is also worthwhile to note that the bootstrapping process WRITES to
> the tree location, thus your permission denied errors.

But…

On Mon, Jul 23, 2012 at 01:32:47PM -0400, W. Trevor King wrote:
> * Couldn't these profile overrides happen in
> "${EPREFIX}/etc/portage/profile" (see portage(5))?

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

On Mon, Jul 23, 2012 at 2:14 PM, Christoph Junghans <ottxor@gentoo.org> wrote:

> Can you give us some motivating number how many packages still need to
> be back-ported to gx86?

% pwd
.../prefix_trunk
% find . -maxdepth 2 -mindepth 2 -type d | wc -l
338

So, roughly 338 packages are still in the prefix repo alone. That is
down ~30 in 5 months given my past analysis:
http://blog.jolexa.net/2012/02/gentoo-prefix-a-look-at-the-number-of-packages/
So, at the current rate, we can expect the migration to take another
~4.5 years.
-Jeremy

2012/7/23 Jeremy Olexa <darkside@gentoo.org>:
> On Mon, Jul 23, 2012 at 2:14 PM, Christoph Junghans <ottxor@gentoo.org> wrote:
>
>> Can you give us some motivating number how many packages still need to
>> be back-ported to gx86?
>
> % pwd
> .../prefix_trunk
> % find . -maxdepth 2 -mindepth 2 -type d | wc -l
> 338
>
> So, roughly 338 packages are still in the prefix repo alone. That is
> down ~30 in 5 months given my past analysis:
> http://blog.jolexa.net/2012/02/gentoo-prefix-a-look-at-the-number-of-packages/
> So, at the current rate, we can expect the migration to take another
> ~4.5 years.
4.5 years (!), that is too long.

Is the strategy still to submit bugs with the changes from prefix and
make them block the tracker #315803?
If so, I will have a look at some easy back-ports and do that.

Christoph

> -Jeremy
>



--
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Hi, Christoph,

Christoph Junghans <ottxor@gentoo.org> writes:

> Is the strategy still to submit bugs with the changes from prefix

yeah.

> and make them block the tracker #315803?

partially.

> If so, I will have a look at some easy back-ports and do that.

Yeah, welcome

Yours,
Benda

On 23-07-2012 14:36:57 -0400, W. Trevor King wrote:
> On Mon, Jul 23, 2012 at 08:07:57PM +0200, Fabian Groffen wrote:
> > The tree is different, so while it sounds reasonable, in reality it is
> > not. Sorry.
>
> Ah, thanks for pointing that out. For some reason I thought that after
>
> On Sun, Apr 1, 2012 at 16:59:53 +0200, Fabian Groffen wrote:
> > The (good) news for users is that all packages from regular Gentoo
> > are now also available for Prefix albeit being masked by missing
> > keywords.
>
> It makes sense that the trees will be different until the EPREFIX
> stuff gets pulled into the main tree though.

The profiles differ, and as Jeremy explained, most of @system packages
are Prefix modified versions. See also:
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay

> On Mon, Jul 23, 2012 at 01:11:50PM -0500, Jeremy Olexa wrote:
> > It is also worthwhile to note that the bootstrapping process WRITES to
> > the tree location, thus your permission denied errors.
>
> But…
>
> On Mon, Jul 23, 2012 at 01:32:47PM -0400, W. Trevor King wrote:
> > * Couldn't these profile overrides happen in
> > "${EPREFIX}/etc/portage/profile" (see portage(5))?

It does this ugly/nasty hack, because environment stuff needs to exist,
uptil the point that you have a sane toolchain. That's about when you
are instructed to run `emerge --sync`, which wipes out these
modifications *on purpose*. The `emerge --sync` hence serves two
reasons, skipping it, or doing it sooner guarantees some problems to
occur.


--
Fabian Groffen
Gentoo on a different level

On Tue, Jul 24, 2012 at 08:37:25AM +0200, Fabian Groffen wrote:
> The profiles differ, and as Jeremy explained, most of @system packages
> are Prefix modified versions. See also:
> http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay

Right, thanks.

> > On Mon, Jul 23, 2012 at 01:11:50PM -0500, Jeremy Olexa wrote:
> > > It is also worthwhile to note that the bootstrapping process WRITES to
> > > the tree location, thus your permission denied errors.
> >
> > But…
> >
> > On Mon, Jul 23, 2012 at 01:32:47PM -0400, W. Trevor King wrote:
> > > * Couldn't these profile overrides happen in
> > > "${EPREFIX}/etc/portage/profile" (see portage(5))?
>
> It does this ugly/nasty hack, because environment stuff needs to exist,
> uptil the point that you have a sane toolchain. That's about when you
> are instructed to run `emerge --sync`, which wipes out these
> modifications *on purpose*. The `emerge --sync` hence serves two
> reasons, skipping it, or doing it sooner guarantees some problems to
> occur.

Ah, that makes a lot of sense. However, if I *was* running the prefix
tree on my base system (assuming the @system changes were dealt with
somehow), I should be able to avoid altering that tree.
Alternatively, if I ran a department server where several users had
their own prefix, there could be a shared tree in a central location.
If a new user wants to start a prefix, they should be able to do so
without checking out a new snapshot. If the changes were made under
"${EPREFIX}/etc", this would work, then just wipe out the changes
instead of calling `emerge --sync` (since presumably the sysadmin had
been keeping the prefix tree synced already).

Also, in Jeremy's bootstrap-gentoo post [1], I think you need

$ ./bootstrap-prefix.sh $EPREFIX latest_tree

before

$ ./bootstrap-prefix.sh $EPREFIX portage

in code listing 1.3, otherwise there's no local tree there to do all
this editing on.


[1]: http://dev.gentoo.org/~darkside/prefix/gentoo/bootstrap-gentoo.xml

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy