[gentoo-dev] PORTAGE_BINHOST Madness

[gentoo-dev] PORTAGE_BINHOST Madness

[Gustavo Felisberto]

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

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


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

Re: [gentoo-dev] PORTAGE_BINHOST Madness

[Mike Frysinger]

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

On Thursday 04 January 2007 20:33, Gustavo Felisberto wrote:
> Ok, so what is diference?

probably the samething as between -k and -K
-mike

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

Re: [gentoo-dev] PORTAGE_BINHOST Madness

[Alec Warner]

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: [gentoo-dev] PORTAGE_BINHOST Madness

[Gustavo Felisberto]

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

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


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

Re: [gentoo-dev] PORTAGE_BINHOST Madness

[Alec Warner]

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

[gentoo-dev] Re: PORTAGE_BINHOST Madness

[Steve Long]

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: [gentoo-dev] Re: PORTAGE_BINHOST Madness

[Ned Ludd]

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

[gentoo-dev] Re: Re: PORTAGE_BINHOST Madness

[Steve Long]

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