Mailing List Archive

some portage-prefix patches
Hi,

after some time using portage-prefix-2.1.14 with some patches now, its
time for me to post these (partially) very useful patches...

Hopefully they will make it at least to the list at once...


[00-check-offset-prefix.patch] (minor)
Just a simple configure-commandline check for valid domain-prefix.

[01-defaultpath.patch] (minor)
Also add "${prefix}/lib/portage/bin" to DEFAULT_PATH, to simplify the
bootstrap process.

[02-ebuildenv-ROOT.patch] (minor)
Moved trailing 'os.sep' from EDEST to ROOT.

[03-eprefix-function.patch] (normal)
Well, eprefix() was not yet present in 2.1.14, but may be already
somewhere in svn (if it exists somewhere).
To get this yet trivial implementation work, [10-portageq-root.patch] is
required.

[04-interactive-ebuild.patch] (enhancement)
The most interesting one: Add interactive-feature to portage, usage:
FEATURES=interactive emerge package
FEATURES=interactive ebuild package.ebuild [unpack|compile|install|...]

[05-checked-binaries.patch] (normal)
Use the binaries figured out by configure for sandbox/bash/mv/prelink.

[06-env-conf+ext.patch] (enhancement)
[07-env-dup.patch] (enhancement)
This two patches are real enhancements, required for my
baselayout-prefix package, which i will eventually post separately
(package & patches).

[08-cnf-typo.patch] (minor)
Just a typo in cnf/Makefile.in, which prevents installation of
PREFIX/etc/make.conf.example

[09-wget-bootstrap.patch] (minor)
Use the wget found by configure, not PREFIX/usr/bin/wget per default in
make.globals. This makes bootstrap easier.

[10-portageq-root.patch] (normal)
Do not pass ROOT to 'portageq', or portageq will try to create
${ROOT}${EPREFIX}/var/tmp, which incorrectly results to
${EDEST}/${EPREFIX}${EPREFIX}/var/tmp
Figured out this with an improved sandbox.

[11-rpath-autofix.patch] (normal)
Do the "Auto fixing rpath" thing for to-be-merged files, not for already
merged ones.

[12-readonly-tree.patch] (normal)
Fix situations where the ebuild cannot be copied twice if tree is
readonly. Maybe the second ebuild-cp could be removed.

best regards, 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
Re: some portage-prefix patches [ In reply to ]
On 25-07-2006 15:04:47 +0200, Michael Haubenwallner wrote:
> Hi,
>
> after some time using portage-prefix-2.1.14 with some patches now, its
> time for me to post these (partially) very useful patches...
>
> Hopefully they will make it at least to the list at once...

Wow. Thanks Michael!

Time is not my best friend at the moment, but I hope these patches can
give a new "impulse" to the prefix portage development!
--
gentoo-osx@gentoo.org mailing list
Re: some portage-prefix patches [ In reply to ]
Cool to see some activity on the list!

Does anyone have a diff from prefix to the portage code it was based
on? I'm interested in seeing how big the patch is. Also since normal
portage appears to have some activity it might be nice to try to keep
in sync with it.

On 7/25/06, Grobian <grobian@gentoo.org> wrote:
> On 25-07-2006 15:04:47 +0200, Michael Haubenwallner wrote:
> > Hi,
> >
> > after some time using portage-prefix-2.1.14 with some patches now, its
> > time for me to post these (partially) very useful patches...
> >
> > Hopefully they will make it at least to the list at once...
>
> Wow. Thanks Michael!
>
> Time is not my best friend at the moment, but I hope these patches can
> give a new "impulse" to the prefix portage development!
> --
> gentoo-osx@gentoo.org mailing list
>
>
--
gentoo-osx@gentoo.org mailing list
Re: some portage-prefix patches [ In reply to ]
> [01-defaultpath.patch] (minor)
> Also add "${prefix}/lib/portage/bin" to DEFAULT_PATH, to simplify the
> bootstrap process.

I do not see how it can aid bootstrap.

> [02-ebuildenv-ROOT.patch] (minor)
> Moved trailing 'os.sep' from EDEST to ROOT.

What is it needed for?

> [03-eprefix-function.patch] (normal)
> Well, eprefix() was not yet present in 2.1.14, but may be already
> somewhere in svn (if it exists somewhere).
> To get this yet trivial implementation work, [10-portageq-root.patch] is
> required.

What is a constant function that always returns the value of EPREFIX if
the input pkg is in the vdb useful for?

> [04-interactive-ebuild.patch] (enhancement)
> The most interesting one: Add interactive-feature to portage, usage:
> FEATURES=interactive emerge package
> FEATURES=interactive ebuild package.ebuild [unpack|compile|install|...]

This is not prefix specific; you should send it to the
gentoo-portage-dev mailing list.

> [11-rpath-autofix.patch] (normal)
> Do the "Auto fixing rpath" thing for to-be-merged files, not for already
> merged ones.

Ditto.

> [12-readonly-tree.patch] (normal)
> Fix situations where the ebuild cannot be copied twice if tree is
> readonly. Maybe the second ebuild-cp could be removed.

Ditto.

> [05-checked-binaries.patch] (normal)
> Use the binaries figured out by configure for sandbox/bash/mv/prelink.

No, we want a path lookup for those to have some flexibility, especially
for bash.

> [08-cnf-typo.patch] (minor)
> Just a typo in cnf/Makefile.in, which prevents installation of
> PREFIX/etc/make.conf.example

Applied.

> [09-wget-bootstrap.patch] (minor)
> Use the wget found by configure, not PREFIX/usr/bin/wget per default in
> make.globals. This makes bootstrap easier.

I do not see how, given that we bootstrap wget too.

> [10-portageq-root.patch] (normal)
> Do not pass ROOT to 'portageq', or portageq will try to create
> ${ROOT}${EPREFIX}/var/tmp, which incorrectly results to
> ${EDEST}/${EPREFIX}${EPREFIX}/var/tmp
> Figured out this with an improved sandbox.

I don't think it's the right place to fix it, I'll look into the
problem. How have you figured it out exactly?

--
Emanuele
--
gentoo-osx@gentoo.org mailing list
Re: some portage-prefix patches [ In reply to ]
exg, thanks for looking into this. One thing I can answer:

On 01-08-2006 15:06:59 +0200, exg@gentoo.org wrote:
> > [03-eprefix-function.patch] (normal)
> > Well, eprefix() was not yet present in 2.1.14, but may be already
> > somewhere in svn (if it exists somewhere).
> > To get this yet trivial implementation work, [10-portageq-root.patch] is
> > required.
>
> What is a constant function that always returns the value of EPREFIX if
> the input pkg is in the vdb useful for?

It's simply a preparation for multi-prefix support, e.g.
eprefix myapplication
that would allow to have a --with-mylib=$(eprefix sys-libs/mylib) in
your configure or something.
At least that was the cool idea we once had, iirc.


--
Fabian Groffen
Gentoo for Mac OS X Project
--
gentoo-osx@gentoo.org mailing list
Re: some portage-prefix patches [ In reply to ]
Thanks for looking through/applying the patches!

Which repository do you use ?
There've been discussions on the list where to host the repository - did
I miss something ?

On Tue, 2006-08-01 at 15:06 +0200, exg@gentoo.org wrote:
> > [01-defaultpath.patch] (minor)
> > Also add "${prefix}/lib/portage/bin" to DEFAULT_PATH, to simplify
> the
> > bootstrap process.
>
> I do not see how it can aid bootstrap.

Well, I do not use the bootstrap-script from the tree, but keep using my
toolsbox, which very-initially was used to bootstrap prefix-portage.
Here I install portage (and bash,wget,sandbox,python,...) to a different
prefix than the domain-prefix I give to portage's configure, to have a
fully portage-managed prefix.
It was a bit easier for me to have this in default path too.
>
> > [02-ebuildenv-ROOT.patch] (minor)
> > Moved trailing 'os.sep' from EDEST to ROOT.
>
> What is it needed for?

This is to be compatible with upstream-portage: in some ebuilds I found
tweaks using "${ROOT}usr/bin", failing if ROOT doesn't have trailing
slash (sys-devel/libperl, dev-lang/perl, net-nds/openldap, ...).
The removal from EDEST is not really necessary, just for some
double-slash prettyness.

> > [04-interactive-ebuild.patch] (enhancement)
> > The most interesting one: Add interactive-feature to portage, usage:
> > FEATURES=interactive emerge package
> > FEATURES=interactive ebuild package.ebuild [unpack|compile|
> install|...]
>
> This is not prefix specific; you should send it to the
> gentoo-portage-dev mailing list.


> > [11-rpath-autofix.patch] (normal)
> > Do the "Auto fixing rpath" thing for to-be-merged files, not for
> already
> > merged ones.
>
> Ditto.
>
Sure, but I do not have this patches for upstream-portage yet, as I need
and use them for prefix-portage.
How much has portage-prefix-2.1.14 to do with official portage-2.1 (from
the SVN-POV) ?

> > [12-readonly-tree.patch] (normal)
> > Fix situations where the ebuild cannot be copied twice if tree is
> > readonly. Maybe the second ebuild-cp could be removed.
>
> Ditto.

For the readonly tree I have to say that I have an improved sandbox,
also wrapping the stat()-call, removing write-permission on readonly
files. Will paste the sandbox-patches soon, but I'm unsure yet if they
are ready for upstream-sandbox.
>
> > [05-checked-binaries.patch] (normal)
> > Use the binaries figured out by configure for
> sandbox/bash/mv/prelink.
>
> No, we want a path lookup for those to have some flexibility,
> especially
> for bash.

Can't remember what the real issue was to me, will do some more testing
without this patch.
>
> > [09-wget-bootstrap.patch] (minor)
> > Use the wget found by configure, not PREFIX/usr/bin/wget per default
> in
> > make.globals. This makes bootstrap easier.
>
> I do not see how, given that we bootstrap wget too.

Ditto.
>
> > [10-portageq-root.patch] (normal)
> > Do not pass ROOT to 'portageq', or portageq will try to create
> > ${ROOT}${EPREFIX}/var/tmp, which incorrectly results to
> > ${EDEST}/${EPREFIX}${EPREFIX}/var/tmp
> > Figured out this with an improved sandbox.
>
> I don't think it's the right place to fix it, I'll look into the
> problem. How have you figured it out exactly?

I have a patched sandbox which can prevent creation of ${D}${EPREFIX}

-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-osx@gentoo.org mailing list
Re: some portage-prefix patches [ In reply to ]
Have done more tests now without some patches:

On Tue, 2006-08-01 at 17:53 +0200, Michael Haubenwallner wrote:
<snip>
> > > [05-checked-binaries.patch] (normal)
> > > Use the binaries figured out by configure for
> > sandbox/bash/mv/prelink.
> >
> > No, we want a path lookup for those to have some flexibility,
> > especially
> > for bash.
>
> Can't remember what the real issue was to me, will do some more testing
> without this patch.

The test for variable 'sandbox_capable' in portage_exec.py relies on
having full path in SANDBOX_BINARY, otherways portage always spits
red("!!! Problem with sandbox binary. Disabling...\n\n")

Path-lookup seems to work for bash & mv, did not use prelink yet.

> >
> > > [09-wget-bootstrap.patch] (minor)
> > > Use the wget found by configure, not PREFIX/usr/bin/wget per default
> > in
> > > make.globals. This makes bootstrap easier.
> >
> > I do not see how, given that we bootstrap wget too.
>
> Ditto.

I do bootstrapping into a separate bootstrap-prefix, giving portage a
completely different '--with-offset-prefix' than it is installed into.
Thus the make.globals setting won't point to a real existing wget
without this patch, and I'd have to create an extra entry in make.conf,
potentially to be forgotten to be removed after 'emerge system' for the
empty domain-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-osx@gentoo.org mailing list
Re: some portage-prefix patches [ In reply to ]
On Tue, 2006-08-01 at 17:53 +0200, Michael Haubenwallner wrote:
> On Tue, 2006-08-01 at 15:06 +0200, exg@gentoo.org wrote:
> > > [01-defaultpath.patch] (minor)
> > > Also add "${prefix}/lib/portage/bin" to DEFAULT_PATH, to simplify
> > the
> > > bootstrap process.
> >
> > I do not see how it can aid bootstrap.
>
> Well, I do not use the bootstrap-script from the tree, but keep using my
> toolsbox, which very-initially was used to bootstrap prefix-portage.
> Here I install portage (and bash,wget,sandbox,python,...) to a different
> prefix than the domain-prefix I give to portage's configure, to have a
> fully portage-managed prefix.
> It was a bit easier for me to have this in default path too.

Now I have my problem again, which caused this patch:

.../sys-devel/patch/patch-2.5.9-r1.ebuild: line 38: emake: command not found

Found: ${prefix}/lib/portage/bin is set as DEFAULT_PATH by
bootstrap-prefix.sh into ${ROOT}/etc/make.conf.

Why not let portage itself know of its paths, rather than having the
"user" set them too ?

-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-osx@gentoo.org mailing list