1 |
On Saturday 14 June 2008 11:53:51 Jorge Manuel B. S. Vicetto wrote: |
2 |
> What's the need for a GLEP covering "live" ebuilds and what's wrong with |
3 |
> -9999 ebuilds? I made myself that question when GLEP54 was submitted and |
4 |
> during the initial discussion. At that time, I wasn't convinced of the |
5 |
> need for such a GLEP. Now I think it can be very useful. |
6 |
> Why did I change my mind? Let's have a concrete use case. |
7 |
> |
8 |
> Updating the live ebuilds for compiz, can be a mess. If the ebuilds |
9 |
> aren't updated in the correct order, the process will fail and leave |
10 |
> users wondering why it failed. What we need is a way to ask the PM to |
11 |
> update compiz-fusion and or fusion-icon and all its "live" deps. |
12 |
|
13 |
Ok, here's a silly idea - |
14 |
|
15 |
tag the ebuilds with metadata. We already have RESTRICT, why not add a "LIVE" |
16 |
variable. The package manager can then treat all ebuilds with that tag |
17 |
differently. Scripts can find them easily. It is forwards and backwards |
18 |
compatible and doesn't cause any user-visible changes. |
19 |
|
20 |
Portage 2.2 and others support sets, portage 2.2 even supports dynamic sets |
21 |
like the "@preserved-rebuild". Shouldn't be that hard to add a "live-ebuilds" |
22 |
dynamic set. |
23 |
(Comments on the feasibility of my idea from portage people appreciated) |
24 |
|
25 |
> Currently, users with Portage have to run something like: |
26 |
> ~ emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \ |
27 |
> ~ compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \ |
28 |
> ~ emerald emerald-themes libcompizconfig compizconfig-python \ |
29 |
> ~ ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \ |
30 |
> ~ compiz-fusion fusion-icon |
31 |
|
32 |
That is the situation where you really love the sets in portage 2.2 - by |
33 |
default portage will re-merge every ebuild from a set when run as "emerge |
34 |
@your-custom-set". Now the overlay maintainer just has to provide the sets |
35 |
with the overlay and users are happy. |
36 |
|
37 |
> The problem with the -9999 ebuilds is that we need to force manually the |
38 |
> reinstalls and that the PM isn't able to determine if a dep needs to be |
39 |
> updated or not from the ebuild revision. |
40 |
|
41 |
If you use sets the updating part is easy, and in situations like emerge -e |
42 |
world you want to update them anyway. |
43 |
|
44 |
> So, running a reinstall with a world update is not desirable and having |
45 |
> to manually mask/unmask live ebuilds can also be a mess. |
46 |
|
47 |
I don't follow - if you want to update everything everything gets upgraded. |
48 |
|
49 |
What you seem to want is a way to make certain revisions "sticky" so that they |
50 |
don't get updated, that would need something like a "package.revisions" file |
51 |
like package.keywords containing "category/package revision" lines. |
52 |
|
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 |
|
58 |
I think that can be easily done if there's an easy way to pull the installed |
59 |
revision and currently available. The last discussions about that stalled |
60 |
without reaching agreement. |
61 |
|
62 |
> But for most cases, if we define a method to identify "live" ebuilds so |
63 |
> that the PM can implement a "--dl-reinstall-scm" like option, would be |
64 |
> "good enough" or at least a "very good start". |
65 |
|
66 |
I agree |
67 |
|
68 |
> Another case where having a method to let PMs identify "live" ebuilds is |
69 |
> important is for running QA scripts like repoman or pcheck. |
70 |
> Instead of having pcheck complain about dropped keywords for version |
71 |
> 9999, I would like to have pcheck complain about "live" ebuilds with |
72 |
> keywords. Not all "live" trees are unstable and thus some might not like |
73 |
> this change. However, if a PM is able to determine "live" ebuilds, it |
74 |
> might be easier to have alternative tests that allow testing for dropped |
75 |
> keywords or for the existence of keywords just for "live" ebuilds. |
76 |
|
77 |
That's what metadata is there for. And ebuilds don't mind carrying a bit |
78 |
more ... after all it's just one line of text. |
79 |
-- |
80 |
gentoo-dev@l.g.o mailing list |