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