Gentoo Logo
Gentoo Spaceship

Installation:
Gentoo Handbook
Installation Docs

Documentation:
Home
Listing
About Gentoo
Philosophy
Social Contract

Resources:
Bug Tracker
Developer List
Discussion Forums
Gentoo BitTorrents
Gentoo Linux Enhancement Proposals
IRC Channels
Mailing Lists
Mirrors
Name and Logo Guidelines
Online Package Database
Security Announcements
Staffing Needs
Supporting Vendors
View our CVS

Graphics:
Logos and themes
Icons
ScreenShots

Miscellaneous Resources:
Gentoo Linux Store
Gentoo-hosted projects
IBM dW/Intel article archive




List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Ryan Hill <dirtyepic@g.o>
Subject: Re: A few questions to our nominees
Date: Sat, 14 Jun 2008 09:04:26 -0600
On Sat, 14 Jun 2008 12:32:22 +0000
Patrick Lauer <bugs@...> wrote:

> Ok, here's a silly idea - 
> 
> tag the ebuilds with metadata. We already have RESTRICT, why not add
> a "LIVE" variable. The package manager can then treat all ebuilds
> with that tag differently. Scripts can find them easily.

Or we could create a scm suffix and not have to parse ebuilds to get
that info.  As an added bonus live ebuilds are instantly identifiable
and can use proper versions numbers instead of 9999.

> Portage 2.2 and others support sets, portage 2.2 even supports
> dynamic sets like the "@preserved-rebuild". Shouldn't be that hard to
> add a "live-ebuilds" dynamic set.

Just as easy with -scm.

> (Comments on the feasibility of my idea from portage people
> appreciated)
> 
> > Currently, users with Portage have to run something like:
> > ~  emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \
> > ~    compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \
> > ~    emerald emerald-themes libcompizconfig compizconfig-python \
> > ~    ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \
> > ~    compiz-fusion fusion-icon
> 
> That is the situation where you really love the sets in portage 2.2 -
> by default portage will re-merge every ebuild from a set when run as
> "emerge @your-custom-set". Now the overlay maintainer just has to
> provide the sets with the overlay and users are happy.

His problem is updating the packages in a specific order.  I don't
remember sets preserving merge order, but then again I wasn't looking.

> > Having a method that
> > lets the user choose that the PM should check the scm tree and
> > update the package if there's a new revision would be even better.
> 
> I think that can be easily done if there's an easy way to pull the
> installed revision and currently available. The last discussions
> about that stalled without reaching agreement.

I could have sworn subversion.eclass already did this but now I can't
find the code.  I might have seen it in an overlay or on the forums.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
Attachment:
signature.asc (PGP signature)
Replies:
Re: A few questions to our nominees
-- Duncan
References:
A few questions to our nominees
-- Piotr Jaroszyński
Re: Re: A few questions to our nominees
-- Tiziano Müller
Re: Re: Re: A few questions to our nominees
-- Jorge Manuel B. S. Vicetto
Re: Re: Re: A few questions to our nominees
-- Patrick Lauer
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: Re: A few questions to our nominees
Next by thread:
Re: A few questions to our nominees
Previous by date:
Re: Re: Re: A few questions to our nominees
Next by date:
Re: A few questions to our nominees


Updated Jun 17, 2009

Donate to support our development efforts.

Gentoo Centric Hosting: vr.org

VR Hosted

Tek Alchemy

Tek Alchemy

SevenL.net

SevenL.net

php|architect

php|architect

Copyright 2001-2007 Gentoo Foundation, Inc. Questions, Comments? Email www@gentoo.org.