Gnome 2 / 3 rename proposal of gnome2/

[Duncan Gibson]

jean.bruenn:
>> I'd like to know whether anyone of you is using "gnome" in lunar and
>> might be able to help updating and testing gnome stuff..
>>
>> Then I'd like to rename "gnome2" to "gnome" because of a few reasons:
>>   a) we can't simple add a gnome3 folder to moonbase, because the
>>      modules within both folders are called exactly the same. So
>>      having gnome2 and gnome3 or gnomeX seperated makes only sense
>>      for a very small amount of modules and only if we name the
>>      modules modulename2 modulename3 modulenameX etc.
>>   b) some modules still have the same version, so they aren't gnome3
>>      or gnome2 they'll work with both. Having them in a gnome2 folder
>>      is just confusing.
>>
>> Anyone against renaming gnome2/ to gnome/?

Me:
> [...]
> My feeling was that even if I had been able to get everything updated
> to the 2.32.0 versions, it would not be possible to have both gnome2
> and gnome3 modules at the top level in lunar. As far as I understand
> it, we would need to create a snapshot of a load of low-level gnome2
> modules by having specific module-version variants. I couldn't see an
> easy way of having gnome2 and gnome3 modules coexisting on the system.
> [...]

After posting this yesterday, the discussion continued briefly on #lunar:

 wdp | auke, say something. how would you implement the gnome stuff if
       you were using gnome. Would you keep gnome2 for compatibility
       and add gnome3 separated? if yes how would you separate them in
       lunar, so that gnome3 stuff doesn't bitch with gnome2 stuff?
auke | split moonbase
auke | dump gnome3 out to a separate moonbase
auke | split out kde, etc etc
auke | that would be one thought

This has been going round in my head overnight. The obvious way would
would simply be to have multiple moonbases for download where each was
customised for a particular set of packages such as gnome2 and gnome3.
These could all be handled internally by using moonbase.git branches.

Another way would be to extend the "profiles" idea in moonbase so that
the DEPENDS file could also specify particular versions of some of the
modules that were required by that profile.

And another would take it a step further, with a new moonbase section
or sections that would be handled slightly differently. The top-level
modules in this section would be meta-modules that specify the use of
a sub-set of moonbase modules with specific versions. Installing one
of these meta-modules could do one of two things:

  1. The meta-module directory would also contain the sub-set of
     modules with specific version required, and these would then
     be used in preference to the main moonbase modules, much like
     zlocal modules take preference now. The meta-module could depend
     on fixed snapshots of modules within the sub-tree, maybe the
     version as part of the name.

  2. The meta-module would download and unpack the sub-set of
     modules into the main moonbase, overwriting anything already
     there, as part of a PRE_BUILD phase.

The disadvantage of all of these approaches is that different parts
of the overall moonbase will require different versions of key modules.
Is there a means of installing them in parallel to avoid conflicts?

There are probably lots of holes in these proposals, so any comments?

Duncan / engelsman