-----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@lists.gentoo.org mailing list
