Mailing List Archive

PORTAGE_BINHOST Madness
According to man portage:


--getbinpkg (-g)
Using the server and location defined in PORTAGE_BINHOST
(see make.conf(5)), portage will download the
information from each binary package found and it will use that
information to help build the dependency
list. This option implies -k. (Use -gK for binary-only merging.)

--getbinpkgonly (-G)
This option is identical to -g, as above, except it will not
use ANY information from the local machine.
All binaries will be downloaded from the remote server without
consulting packages existing in the local
packages directory.


Ok, so what is diference? -g will fetch ALL packages in PORTAGE_BINHOST and use
them to construct the deps and the other......



--
Gustavo Felisberto
(HumpBack)
Web: http://dev.gentoo.org/~humpback
Blog: http://blog.felisberto.net/
------------
It's most certainly GNU/Linux, not Linux. Read more at
http://www.gnu.org/gnu/why-gnu-linux.html .
-------------
Re: PORTAGE_BINHOST Madness [ In reply to ]
On Thursday 04 January 2007 20:33, Gustavo Felisberto wrote:
> Ok, so what is diference?

probably the samething as between -k and -K
-mike
Re: PORTAGE_BINHOST Madness [ In reply to ]
Mike Frysinger wrote:
> On Thursday 04 January 2007 20:33, Gustavo Felisberto wrote:
>> Ok, so what is diference?
>
> probably the samething as between -k and -K
> -mike

A more verbose answer:

-k says "use binary packages if possible, otherwise use ebuilds"
-K says "use only binary packages, fail if you can't create a depgraph"

-g says "use remote binary packages if possible, otherwise use ebuilds"
-G says "only use remove binary packages, fail if you can't create a
depgraph"


I'd have to double check -g to make sure ebuilds are the fallback; you
may be able to do something like

emerge -g -k

but in this case I'm pretty sure the remote binrepo will 'shadow' the
local one, I'd have to ask Zac to be sure ;)
--
gentoo-dev@gentoo.org mailing list
Re: PORTAGE_BINHOST Madness [ In reply to ]
Alec Warner wrote:
> Mike Frysinger wrote:
>> On Thursday 04 January 2007 20:33, Gustavo Felisberto wrote:
>>> Ok, so what is diference?
>> probably the samething as between -k and -K
>> -mike
>
> A more verbose answer:
>
> -k says "use binary packages if possible, otherwise use ebuilds"
> -K says "use only binary packages, fail if you can't create a depgraph"
>
> -g says "use remote binary packages if possible, otherwise use ebuilds"
> -G says "only use remove binary packages, fail if you can't create a
> depgraph"
>
>
> I'd have to double check -g to make sure ebuilds are the fallback; you
> may be able to do something like
>
> emerge -g -k
>
> but in this case I'm pretty sure the remote binrepo will 'shadow' the
> local one, I'd have to ask Zac to be sure ;)
My main issue is with size. Right now portage has to pull ALL the packages in
the PORTAGE_BINHOST to create the dep tree. Is there a way for me to say:

emerge -u --use-bynary-packages-if-possible system and portage will build the
dep tree based on the local portage tree, then it will try to fetch the updated
packages and see if the deps are ok.

--
Gustavo Felisberto
(HumpBack)
Web: http://dev.gentoo.org/~humpback
Blog: http://blog.felisberto.net/
------------
It's most certainly GNU/Linux, not Linux. Read more at
http://www.gnu.org/gnu/why-gnu-linux.html .
-------------
Re: PORTAGE_BINHOST Madness [ In reply to ]
Gustavo Felisberto wrote:
> My main issue is with size. Right now portage has to pull ALL the packages in
> the PORTAGE_BINHOST to create the dep tree. Is there a way for me to say:
>
> emerge -u --use-bynary-packages-if-possible system and portage will build the
> dep tree based on the local portage tree, then it will try to fetch the updated
> packages and see if the deps are ok.
>

meh..You want to build a depgraph on local ebuilds, and then try to find
matching binpkgs after the fact? I'd imagine you'd have a lot of
trouble finding matching packages, tbh :)

Ebuilds in the tree will get updated, or your local USE flags will
change; your binary packages won't match in either case here, because
the tree has a more up to date package or a package with correct flags.
Thats why the binary repo is used for the deptree generation.

Talk to solar about binhost, I know he has a better implementation lying
around; it's a matter of finalizing it ;)
--
gentoo-dev@gentoo.org mailing list
Re: Re: PORTAGE_BINHOST Madness [ In reply to ]
On Sun, 2007-01-07 at 05:16 +0000, Steve Long wrote:
> Alec Warner wrote:
> > Talk to solar about binhost, I know he has a better implementation lying
> > around; it's a matter of finalizing it ;)

> solar: where is it on your site?

Tip: If you want me to respond to something that directed to me
it's best to CC: me directly as it's easy to miss threads on high
volume lists.

I use the qmerge applet from portage-utils to grab the pkgs to the
localhost then emerge -Kpv $pkg.

So on a fresh install I do something like

wget hardened-tarball.tbz2
unpack
emerge portage-utils
set binhost
qmerge -f $(qlist -IC)
emerge -C pam-login
emerge -Ke system


otherwise I just qmerge -f $pkg ;
emerge -Kpv $pkg

The qmerge applet requires the use of the genpkgindex util on the
remote bin repo. I know pkgcore is going to start using this same
format for it's remote bin repo stuff. I talked with Zac (zmedico)
last week about portage supporting it also. I think he is keen on
it but the tool will need love on solving the $PN conflicts.
Between us 3 we will come up with a standard sooner or later.
(probably later vs sooner)

http://sources.gentoo.org/viewcvs.py/*checkout*/gentoolkit/trunk/src/genpkgindex/genpkgindex
it generates output like the following.
http://tinderbox.dev.gentoo.org/hardened/x86/Packages



--
Ned Ludd <solar@gentoo.org>
Gentoo Linux

--
gentoo-dev@gentoo.org mailing list
Re: PORTAGE_BINHOST Madness [ In reply to ]
Alec Warner wrote:
> Talk to solar about binhost, I know he has a better implementation lying
> around; it's a matter of finalizing it ;)
solar: where is it on your site?

--
gentoo-dev@gentoo.org mailing list
Re: Re: PORTAGE_BINHOST Madness [ In reply to ]
Ned Ludd wrote:
>> solar: where is it on your site?
>
> Tip: If you want me to respond to something that directed to me
> it's best to CC: me directly as it's easy to miss threads on high
> volume lists.
>
Understood. (I don't use email client for news, but I'll fwd in future.)

> I use the qmerge applet from portage-utils to grab the pkgs to the
> localhost then emerge -Kpv $pkg.
>
..
> The qmerge applet requires the use of the genpkgindex util on the
> remote bin repo. I know pkgcore is going to start using this same
> format for it's remote bin repo stuff. I talked with Zac (zmedico)
> last week about portage supporting it also. I think he is keen on
> it but the tool will need love on solving the $PN conflicts.
> Between us 3 we will come up with a standard sooner or later.
> (probably later vs sooner)
>
>
http://sources.gentoo.org/viewcvs.py/*checkout*/gentoolkit/trunk/src/genpkgindex/genpkgindex
> it generates output like the following.
> http://tinderbox.dev.gentoo.org/hardened/x86/Packages
>
That is beautiful!


--
gentoo-dev@gentoo.org mailing list