-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

Those using paludis need just to run[1]:
~  paludis -pi1 compiz-fusion --dl-reinstall-scm always --compact \
~    --show-reasons none

[1] - I don't run paludis myself. That command is what some paludis
users run to update the compiz ebuilds.

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.

Tiziano Müller wrote:
| Luca Barbato wrote:
|
|> Tiziano Müller wrote:
|>> @lu_zero: I don't think we can get away without having the pm know
what a
|>> live-ebuild exactly is and when to re-install it.
|> a live ebuild is a template, every time it has to be evaluated it acts
|> as a normal ebuild with the version mentioned and _preN+1 postponed,
|> preN is the highest preN present, if present.
| Sorry, but I don't want to re-install a snapshot every time I do a world
| update. And I also don't want to manually mask/unmask the live ebuilds.
| I either want to be able to specify a time interval after which live
ebuilds
| should be refetched or being able to manually re-install them (second use
| case is trivial).
|

So, running a reinstall with a world update is not desirable and having
to manually mask/unmask live ebuilds can also be a mess.
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.
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".

One option that might be interesting to avoid having the PM update *all*
live deps, would be to have an option to run the update for packages
inside a set. In this case, for example, I could just add all the compiz
packages to a set and not worry about the PM updating also all the live
kde packages.

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.

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhTsU8ACgkQcAWygvVEyAK5JwCfQlflTUNi9hDcUgwgxgAyUbS6
lakAoJhyQG4KsnyfRJez6edhuKQmVVOL
=y7PF
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list