| 1 |
On Sat, 14 Jun 2008 12:32:22 +0000 |
| 2 |
Patrick Lauer <bugs@××××××××××××××××××××××.org> wrote: |
| 3 |
|
| 4 |
> Ok, here's a silly idea - |
| 5 |
> |
| 6 |
> tag the ebuilds with metadata. We already have RESTRICT, why not add |
| 7 |
> a "LIVE" variable. The package manager can then treat all ebuilds |
| 8 |
> with that tag differently. Scripts can find them easily. |
| 9 |
|
| 10 |
Or we could create a scm suffix and not have to parse ebuilds to get |
| 11 |
that info. As an added bonus live ebuilds are instantly identifiable |
| 12 |
and can use proper versions numbers instead of 9999. |
| 13 |
|
| 14 |
> Portage 2.2 and others support sets, portage 2.2 even supports |
| 15 |
> dynamic sets like the "@preserved-rebuild". Shouldn't be that hard to |
| 16 |
> add a "live-ebuilds" dynamic set. |
| 17 |
|
| 18 |
Just as easy with -scm. |
| 19 |
|
| 20 |
> (Comments on the feasibility of my idea from portage people |
| 21 |
> appreciated) |
| 22 |
> |
| 23 |
> > Currently, users with Portage have to run something like: |
| 24 |
> > ~ emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \ |
| 25 |
> > ~ compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \ |
| 26 |
> > ~ emerald emerald-themes libcompizconfig compizconfig-python \ |
| 27 |
> > ~ ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \ |
| 28 |
> > ~ compiz-fusion fusion-icon |
| 29 |
> |
| 30 |
> That is the situation where you really love the sets in portage 2.2 - |
| 31 |
> by default portage will re-merge every ebuild from a set when run as |
| 32 |
> "emerge @your-custom-set". Now the overlay maintainer just has to |
| 33 |
> provide the sets with the overlay and users are happy. |
| 34 |
|
| 35 |
His problem is updating the packages in a specific order. I don't |
| 36 |
remember sets preserving merge order, but then again I wasn't looking. |
| 37 |
|
| 38 |
> > Having a method that |
| 39 |
> > lets the user choose that the PM should check the scm tree and |
| 40 |
> > update the package if there's a new revision would be even better. |
| 41 |
> |
| 42 |
> I think that can be easily done if there's an easy way to pull the |
| 43 |
> installed revision and currently available. The last discussions |
| 44 |
> about that stalled without reaching agreement. |
| 45 |
|
| 46 |
I could have sworn subversion.eclass already did this but now I can't |
| 47 |
find the code. I might have seen it in an overlay or on the forums. |
| 48 |
|
| 49 |
|
| 50 |
-- |
| 51 |
gcc-porting, by design, by neglect |
| 52 |
treecleaner, for a fact or just for effect |
| 53 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |
Archives