[xen-tools-dev] Migration and Consolidation (-common)

[Stéphane Jourdois]

Le 31/10/2010 11:49, Dmitry Nedospasov a écrit :
> Hey Guys,

Hi Dmitry, Axel and Stephane speaking here :)

> I think we should hammer out a timeline for doing a major overhaul of
> the scripts and more importantly, how we're going to do it (i.e. what
> the hooks are gonna be named).

Axel says: I prefer roadmaps to timelines, i.e. the Debian way "it's 
ready when it's ready". But we should write down a more precise plan 
indeed.

> As you all know we've been planning to minimize code duplication mainly
> by consolidating the scripts into "dpkg-common", "rpm-common" etc...
>
> The question is then how to handle the parts that are release or distro
> specific (i.e. where Lucid differs from Hardy). Here I see 3 options:
>
> 1.) Have distro specific scripts in a separate per-distro hooks
>      directory (like it is now, but with also with -common scripts)
>
>      + We could have these scripts take priority over the "default"
>        "common" (dpkg-/rpm-) scripts
>      + If a distro-specific hook comes along that isn't present in
>        "common", we can just add it to that distro directory
>      - Will still lead to some code duplication (consider install-kernel)
>      - Might lead to more confusion than we have now
>
> A slight variation on this would be to run the distro specific scripts
> later and "fix" what the common scripts got wrong, but to me this isn't
> very attractive.
>
> 2.) Get rid of the distro specific directory folder all together and
>      pass the dist parameter to the "common" scripts, and have a switch
>      case install the distro specific parts.
>
>      + Might yield code that is more readable and better documented

Axel says: That's the far goal.

>      - Larger "common" scripts

Axel says: That's not a problem.

>      - Distro-specific hooks are harder to implement

Axel says: We think we can fix that issue:

Stephane suggested to clearly distinguish between hooks and roles: Hooks 
are just changed for supporting new distributions. User-specific 
contributions should go into roles.

So in future, hooks should go to e.g. /usr/share/xen-tools/ or 
/usr/local/share/xen-tools/ but no more /etc/ while roles should go to 
/etc/...

Stephane says: Perhaps at some point after code de-duplication (done in 
sh), we will even be able to translate hooks in perl, and then move them 
to /usr/lib/perl/Xen/Tools/something.

> I find that the last "-" in this case is still a big issue, I can easily
> imagine us seeking to add a script in the future that was is not present
> in the "common" scripts.

Stephane says: common script can become a common.d list of scripts, each 
one about a specific subject:
  - package management,
  - network configuration,
  - file modifications,
  - etc.

> 3.) Create a call in the scripts to call the distro-specific parts.
>      + Would solve code duplication problems
>      - Manageability, it might be necessary to retroactively move parts out
>        of common, leading to a similar situation to what we have now
>      - Readability, or lack there of
>
> Anyway, any of the three are better than what we have right now. I
> personally like 1 because it seems to be the most modular option, 2
> however would have the least code duplication.
>
> I'm eager to hear what you all think! Remember, I think in some ways it
> would make sense to make a mix of all 3, but for the purposes of
> discussion I tried to make them as mutually-excluding as possible ;)

Stephane says: We do agree that a mix of at least your 2) and 3) are wanted.
In the meantime, here is a suggestion for a roadmap for hooks :
  - write incremental and small patches to remove every code duplication 
we can find, moving things to common when needed ; do not create 
common-$dist at least at this point ;
  - try to move to your 3), i.e. implement as much as possible in hooks 
as function calls, functions being defined in common.sh ;
  - move the common.sh call from hooks to xen-create-image ;
  - when hooks are reduced to their minimal state, we'll think again 
about two things:
    - translating hooks to perl (that would permit better error 
management things), and
     - distribution/release "agnosticism", i.e. do we need common-$dist, 
or do we prefer to have distribution characteristics specified as config 
scripts, i.e. inifiles, not scripts any more ?

> P.S. On a side note, do we pass dist to the role scripts? This is
> someting we should do if we don't do that yet.

Yes we do, as environment variables (look for exportEnvironment sub), 
but no provided role does use that feature.


Thanks Dmitry about those usefull thoughts !
Stephane and Axel from mini debconf, Paris.