On Saturday 14 June 2008 11:53:51 Jorge Manuel B. S. Vicetto wrote:
> What's the need for a GLEP covering "live" ebuilds and what's wrong with
> -9999 ebuilds? I made myself that question when GLEP54 was submitted and
> during the initial discussion. At that time, I wasn't convinced of the
> need for such a GLEP. Now I think it can be very useful.
> Why did I change my mind? Let's have a concrete use case.
>
> Updating the live ebuilds for compiz, can be a mess. If the ebuilds
> aren't updated in the correct order, the process will fail and leave
> users wondering why it failed. What we need is a way to ask the PM to
> update compiz-fusion and or fusion-icon and all its "live" deps.

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. It is forwards and backwards 
compatible and doesn't cause any user-visible changes.

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

> The problem with the -9999 ebuilds is that we need to force manually the
> reinstalls and that the PM isn't able to determine if a dep needs to be
> updated or not from the ebuild revision.

If you use sets the updating part is easy, and in situations like emerge -e 
world you want to update them anyway.

> So, running a reinstall with a world update is not desirable and having
> to manually mask/unmask live ebuilds can also be a mess.

I don't follow - if you want to update everything everything gets upgraded.

What you seem to want is a way to make certain revisions "sticky" so that they 
don't get updated, that would need something like a "package.revisions" file 
like package.keywords containing "category/package revision" lines.

> Having a method that lets the user choose to reinstall all the live
> ebuilds every N days is an interesting option. 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.

> But for most cases, if we define a method to identify "live" ebuilds so
> that the PM can implement a "--dl-reinstall-scm" like option, would be
> "good enough" or at least a "very good start".

I agree

> Another case where having a method to let PMs identify "live" ebuilds is
> important is for running QA scripts like repoman or pcheck.
> Instead of having pcheck complain about dropped keywords for version
> 9999, I would like to have pcheck complain about "live" ebuilds with
> keywords. Not all "live" trees are unstable and thus some might not like
> this change. However, if a PM is able to determine "live" ebuilds, it
> might be easier to have alternative tests that allow testing for dropped
> keywords or for the existence of keywords just for "live" ebuilds.

That's what metadata is there for. And ebuilds don't mind carrying a bit 
more ... after all it's just one line of text.
-- 
gentoo-dev@g.o mailing list