FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-30-2010, 10:41 AM
Bertrand Jacquin
 
Default Building custom package for multi-arch/system

D'ar yaou 28 a viz Genver 2010 e 23 eur 31, Robin H. Johnson he deus skrivet :
> On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote:
> > So, I did a wrapper to emerge --buildpkg to create tbz2 with SHA1 in
> > names function of USE, like :
> > CHOST="x86_64-pc-linux-gnu"
> > ACCEPT_KEYWORDS="amd64"
> > tcpdump
> >
> > USE="+chroot +ipv6 -ssl -test -samba -smi"
> > is placed under /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+2bf4bfffad82d4ae519f76770b4f7db7 b4416738.tbz2
> >
> > USE="+chroot +ipv6 +ssl -test +samba -smi"
> > is placed under /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+5e099e8337e4cadfceda6ccf4c881fbb 495980bd.tbz2
> A word of warning on this.
>
> Simply capturing the USE flags is not enough, the libraries that a
> binary is linked against can cause problems as well, as the dependency
> imposed by linking is much stricter than the RDEPEND in the ebuild.
>
> tcpdump for example has:
> RDEPEND="... ssl? ( >=dev-libs/openssl-0.9.6m )"

Of course, but real *DEPEND could be added in the xpak part of tbz2 and
resolv depedencies by the way.

> But if you built and linked against openssl-0.9.7*, then upgraded to
> openssl-0.9.8, you can expect breakage.
>
> Similar things happened with binaries linked against libmysqlclient in
> the past.
>
> As to my own take on a solution to the problem for work stuff, we simply
> maintain one chroot per unique environment (we only have 5 envs), and
> build in the chroot, then use those binpkgs on the boxes.

I did that already, but it's a bit heavy to maintain and do much
repetitive (maybe it's not the good word) as many packages would be
build with the same USE (in the case of same arch, chost etc).

--
Beber
 
Old 01-30-2010, 10:43 AM
Bertrand Jacquin
 
Default Building custom package for multi-arch/system

D'ar gwener 29 a viz Genver 2010 e 00 eur 23, Philipp Riegger he deus skrivet :
> On Thu, 28 Jan 2010 16:17:41 +0100
> Beber <beber@meleeweb.net> wrote:
>
> > So, I did a wrapper to emerge --buildpkg to create tbz2 with SHA1 in
> > names function of USE, like :
> > CHOST="x86_64-pc-linux-gnu"
> > ACCEPT_KEYWORDS="amd64"
> > tcpdump
> >
> > USE="+chroot +ipv6 -ssl -test -samba -smi"
> > is placed
> > under /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+2bf4bfffad82d4ae519f76770b4f7db7 b4416738.tbz2
> >
> > USE="+chroot +ipv6 +ssl -test +samba -smi"
> > is placed
> > under /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+5e099e8337e4cadfceda6ccf4c881fbb 495980bd.tbz2
>
> So these are the SHA1 sums of the packages? Nice.

No, the SHA1 is USE var SHA1.

sha1sum <<< "$USE"

--
Beber
 
Old 01-30-2010, 10:59 AM
Zac Medico
 
Default Building custom package for multi-arch/system

On 01/28/2010 09:24 PM, Max Arnold wrote:
> On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote:
>> So, do you guys plan to implement a such thing ? That's one of the
>> features that is mostly missing imho. The principal miss in on client
>> side as I have tools to manage packages but would like to not have too
>> much specific scripts on client side.
>
> I like the way it done in OpenEmbedded. You have the tree of recipes (think of portage tree)
> and bunch of targets. For each target BitBake can generate binary release and package feed.
> Client package management is lightweight and does not require BitBake, recipes tree and even
> python. At least this is my lame interpretation of how it works

You can do something similar using the emerge --config-root option.
You'd just use a different --config-root for each target, and each
of those would have a separate $PKGDIR.

> Maybe this "metadistribution" approach is cleaner than binary package support in emerge. If
> user wants to compile packages on the client, he uses portage. If not - he can setup build
> server for multiple targets and completely drop portage from client machines. The only thing
> client should know is feed url with full list of binary packages. And I do not think client
> should deal with USE flags - for large installations unification is the only sane way to scale.

The clients need sys-apps/portage installed, but not the whole
portage tree (although the profiles directory can be useful for
the profile and package moves). The clients should set
PORTAGE_BINHOST in make.conf, so that binary packages are
automatically downloaded with the emerge -g option.
--
Thanks,
Zac
 
Old 01-30-2010, 02:13 PM
Max Arnold
 
Default Building custom package for multi-arch/system

On Sat, Jan 30, 2010 at 03:59:27AM -0800, Zac Medico wrote:
> On 01/28/2010 09:24 PM, Max Arnold wrote:
> > On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote:
> >> So, do you guys plan to implement a such thing ? That's one of the
> >> features that is mostly missing imho. The principal miss in on client
> >> side as I have tools to manage packages but would like to not have too
> >> much specific scripts on client side.
> >
> > I like the way it done in OpenEmbedded. You have the tree of recipes (think of portage tree)
> > and bunch of targets. For each target BitBake can generate binary release and package feed.
> > Client package management is lightweight and does not require BitBake, recipes tree and even
> > python. At least this is my lame interpretation of how it works
>
> You can do something similar using the emerge --config-root option.
> You'd just use a different --config-root for each target, and each
> of those would have a separate $PKGDIR.

Can someone share his experience of using Catalyst or Metro as generator of binary package
updates for precompiled client machines? How smooth it is in the long run?
 
Old 01-30-2010, 03:20 PM
Jacob Godserv
 
Default Building custom package for multi-arch/system

On Sat, Jan 30, 2010 at 10:13, Max Arnold <lwarxx@gmail.com> wrote:
> Can someone share his experience of using Catalyst or Metro as generator of binary package
> updates for precompiled client machines? *How smooth it is in the long run?

I use metro (wrote a little HOWTO on it: <
http://neuvoo.org/wiki/index.php?title=Create_Image/Building >) and it
asks emerge to --buildpkg at every stage. It keeps binaries separate
per stage. The end result, as long as you told it not to clean, is
three folders with a binary repo in each. It will re-use these
binaries in future stage builds, if you don't clean it out.

If you don't want it building stages, it's very easy to configure
metro to do exactly what you want. It still has to be figured out to
some extent, but the format is much simpler than catalyst and takes
less time to customize properly.

I'm not sure what "long run" looks like as I have yet to enter the
"long run". As far as I can tell, metro will always build and update
binary repositories when you ask it to.

--
Jacob

"For then there will be great distress, unequaled
from the beginning of the world until now — and never
to be equaled again. If those days had not been cut
short, no one would survive, but for the sake of the
elect those days will be shortened."

Are you ready?
 
Old 01-30-2010, 05:11 PM
Duncan
 
Default Building custom package for multi-arch/system

Zac Medico posted on Sat, 30 Jan 2010 03:59:27 -0800 as excerpted:

> The clients need sys-apps/portage installed, but not the whole portage
> tree (although the profiles directory can be useful for the profile and
> package moves). The clients should set PORTAGE_BINHOST in make.conf, so
> that binary packages are automatically downloaded with the emerge -g
> option.

Thanks. I knew the PORTAGE_BINHOST and --config-root bits, but hadn't
thought about the tree not being needed, save for the profiles. I
recently setup a netbook based on a Gentoo image compiled elsewhere, and
while it's now functional, I'm still tweaking stuff, including the portage
arrangement. That I don't need the entire gentoo tree for emerging
binpkgs is thus quite interesting new information at this point. =:^)

Does that happen to be documented anywhere? I'd not seen it before.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 01-30-2010, 08:24 PM
Zac Medico
 
Default Building custom package for multi-arch/system

On 01/30/2010 10:11 AM, Duncan wrote:
> Thanks. I knew the PORTAGE_BINHOST and --config-root bits, but hadn't
> thought about the tree not being needed, save for the profiles. I
> recently setup a netbook based on a Gentoo image compiled elsewhere, and
> while it's now functional, I'm still tweaking stuff, including the portage
> arrangement. That I don't need the entire gentoo tree for emerging
> binpkgs is thus quite interesting new information at this point. =:^)
>
> Does that happen to be documented anywhere? I'd not seen it before.

No, not really. The binhost support was updated in portage-2.1.6,
with support for the $PKGDIR/Packages file. Since then it's a lot
more appealing.
--
Thanks,
Zac
 

Thread Tools




All times are GMT. The time now is 08:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org