1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
What's the need for a GLEP covering "live" ebuilds and what's wrong with |
5 |
- -9999 ebuilds? I made myself that question when GLEP54 was submitted and |
6 |
during the initial discussion. At that time, I wasn't convinced of the |
7 |
need for such a GLEP. Now I think it can be very useful. |
8 |
Why did I change my mind? Let's have a concrete use case. |
9 |
|
10 |
Updating the live ebuilds for compiz, can be a mess. If the ebuilds |
11 |
aren't updated in the correct order, the process will fail and leave |
12 |
users wondering why it failed. What we need is a way to ask the PM to |
13 |
update compiz-fusion and or fusion-icon and all its "live" deps. |
14 |
|
15 |
Currently, users with Portage have to run something like: |
16 |
~ emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \ |
17 |
~ compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \ |
18 |
~ emerald emerald-themes libcompizconfig compizconfig-python \ |
19 |
~ ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \ |
20 |
~ compiz-fusion fusion-icon |
21 |
|
22 |
Those using paludis need just to run[1]: |
23 |
~ paludis -pi1 compiz-fusion --dl-reinstall-scm always --compact \ |
24 |
~ --show-reasons none |
25 |
|
26 |
[1] - I don't run paludis myself. That command is what some paludis |
27 |
users run to update the compiz ebuilds. |
28 |
|
29 |
The problem with the -9999 ebuilds is that we need to force manually the |
30 |
reinstalls and that the PM isn't able to determine if a dep needs to be |
31 |
updated or not from the ebuild revision. |
32 |
|
33 |
Tiziano Müller wrote: |
34 |
| Luca Barbato wrote: |
35 |
| |
36 |
|> Tiziano Müller wrote: |
37 |
|>> @lu_zero: I don't think we can get away without having the pm know |
38 |
what a |
39 |
|>> live-ebuild exactly is and when to re-install it. |
40 |
|> a live ebuild is a template, every time it has to be evaluated it acts |
41 |
|> as a normal ebuild with the version mentioned and _preN+1 postponed, |
42 |
|> preN is the highest preN present, if present. |
43 |
| Sorry, but I don't want to re-install a snapshot every time I do a world |
44 |
| update. And I also don't want to manually mask/unmask the live ebuilds. |
45 |
| I either want to be able to specify a time interval after which live |
46 |
ebuilds |
47 |
| should be refetched or being able to manually re-install them (second use |
48 |
| case is trivial). |
49 |
| |
50 |
|
51 |
So, running a reinstall with a world update is not desirable and having |
52 |
to manually mask/unmask live ebuilds can also be a mess. |
53 |
Having a method that lets the user choose to reinstall all the live |
54 |
ebuilds every N days is an interesting option. Having a method that lets |
55 |
the user choose that the PM should check the scm tree and update the |
56 |
package if there's a new revision would be even better. |
57 |
But for most cases, if we define a method to identify "live" ebuilds so |
58 |
that the PM can implement a "--dl-reinstall-scm" like option, would be |
59 |
"good enough" or at least a "very good start". |
60 |
|
61 |
One option that might be interesting to avoid having the PM update *all* |
62 |
live deps, would be to have an option to run the update for packages |
63 |
inside a set. In this case, for example, I could just add all the compiz |
64 |
packages to a set and not worry about the PM updating also all the live |
65 |
kde packages. |
66 |
|
67 |
Another case where having a method to let PMs identify "live" ebuilds is |
68 |
important is for running QA scripts like repoman or pcheck. |
69 |
Instead of having pcheck complain about dropped keywords for version |
70 |
9999, I would like to have pcheck complain about "live" ebuilds with |
71 |
keywords. Not all "live" trees are unstable and thus some might not like |
72 |
this change. However, if a PM is able to determine "live" ebuilds, it |
73 |
might be easier to have alternative tests that allow testing for dropped |
74 |
keywords or for the existence of keywords just for "live" ebuilds. |
75 |
|
76 |
- -- |
77 |
Regards, |
78 |
|
79 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
80 |
Gentoo- forums / Userrel / SPARC / KDE |
81 |
-----BEGIN PGP SIGNATURE----- |
82 |
Version: GnuPG v2.0.9 (GNU/Linux) |
83 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
84 |
|
85 |
iEYEARECAAYFAkhTsU8ACgkQcAWygvVEyAK5JwCfQlflTUNi9hDcUgwgxgAyUbS6 |
86 |
lakAoJhyQG4KsnyfRJez6edhuKQmVVOL |
87 |
=y7PF |
88 |
-----END PGP SIGNATURE----- |
89 |
-- |
90 |
gentoo-dev@l.g.o mailing list |