Handling renamed modules – An idea

A few days ago we had a little discussion on IRC how to handle renamed modules (once again). Due to the renamed KDE modules a few users had a broken Box because Lunar Linux isn’t keeping track of renamed modules – So, if a module gets renamed it looks like the module got removed and nobody knows how the new module might be called, except he’s searching for that. That leads to a lot of missing modules after an update.

zbiggy suggested the use of a table to keep track of such modules, his idea got rejected, tho. To read more about his initial idea/implementation take a look at this mail.

However, we still need a solution to handle renamed modules better than we do currently, so I came up with the following snippets:

Patch 1 to /var/lib/lunar/functions/modules.lunar

> # function : module_superseeded
> # usage    : module_superseeded $MODULE
> # purpose  : checks if $MODULE is superseeded by another MODULE
> # return   : returns 0 if superseeded, 255 else
> module_superseeded() {
>   if run_details $1 &>/dev/null ; then
>     if [ ! -z "$SUPERSEEDED" ]; then
>       return 0;
>     fi
>   fi
>   return 255
> }
>       fi
>     else
>       # run_details $MODULE worked; thus the module is installed
>       # let's check if it got renamed.
>       if module_superseeded $MODULE ; then
>         message
>         if query "Do you want to switch to
>           lrm $MODULE
>           lin $SUPERSEEDED
>           continue
>         else
>           message
> be renamed manually later${DEFAULT_COLOR}";
>         fi

Patch 2 to /sbin/lin

>           elif module_superseeded $MODULE ; then
>             error_message
> "${LRM_COLOR}Notice:${DEFAULT_COLOR}${MESSAGE_COLOR} The module is
> superseeded by
>             error_message "please lin that one
> instead.${DEFAULT_COLOR}"
>             continue

Remember, the goal was to keep it very simple. The above code changes the way, developers have to handle modules (if they rename them) a little bit. They have to set the SUPERSEEDED flag in DETAILS file to get it working. The devs I talked to have been okay with this approach.

renamed gcc to wdp-rulez

[lunar] root@lunar /var/lib/lunar/moonbase/compilers # purge_modules
+ Discovering modules that were removed from moonbase
flash-plugin-10 was removed from /var/lib/lunar/moonbase
flash-plugin-10: Do you want to remove flash-plugin-10 ? [y] n
flash-plugin-10 is kept and can be removed manually later
gcc got renamed to wdp-rulez
gcc: Do you want to switch to wdp-rulez ? [y] n
gcc is kept and can be renamed manually later
[lunar] root@lunar /var/lib/lunar/moonbase/compilers #

For devs handling of modules changes to this:

The proper way to handle renamed modules is now:

  1. Copy the module to it’s new place and rename the copy.
    e.g: cp -rva compilers/gcc compilers/newgcc
  2. Move the old one to zdeprecated
    e.g: mv compilers/gcc zdeprecated/gcc
  3. Remove everything _except_ DETAILS from zdeprecated/gcc/*
  4. Add: SUPERSEEDED=newgcc to DETAILS
    e.g: echo “SUPERSEEDED=newgcc” >> zdeprecated/gcc/DETAILS

El_Angelo suggested that we make sure that people can’t lin/get
the new module if they “lin” the old one.


root@lunar ~ # lin gcc
+ Spawning download manager
+ download queue:   gcc
Notice: The module is superseeded by  wdp-rulez
please lin that one instead.
root@lunar ~ #

That way we’re making sure, that nobody installs a package which
is superseeded by another.

Let’s see whether this will go into Lunar :)

This entry was posted in the daily insanity. Bookmark the permalink.

5 Responses to Handling renamed modules – An idea

  1. dveatch says:

    That looks doable. But I think it could use a little more automation so the dev does not need to manually copy/rename modules. Maybe a lvu depereciate, lvu move or lvu rename command that will handle the renaming, removing all scripts but DETAILS and inserting a SUPERCEDED to DETAILS.

  2. dveatch says:

    Thinking about it some more I wonder if moving the “old” module to zdepreciated is really needed. The whole point of renaming a module, is to bring the modules name more in line with the naming convention of the the tarball. There are other reasons sure, but the end result is to get rid of the the current module. I would like to see a mechanism that will remove the zdepreciated module after the new module has been installed.

    That is not a hard and fast issue but just a little concerned zdepreciated will start filling up with superseded modules.

  3. Florin says:

    Maybe we can put a SUPERCEED field in the new modules and keep no more the old one. This way we may use the old name as an alias of the new one. The only trouble i see here is in the case a new module is added to the moonbase having an old, superceeded one. This might create confusion. A possible solution could be to reject the creation of such a new module (old name reserved by the SUPERCEED field) or remove the SUPERCEED field and do create the new module.

  4. wdp says:

    Heh. No Feedback by Ratler so far for it. But I got some Feedback by Auke -> He suggested another way to do this, inclusive merging CONFLICTS and DEPENDS. Let’s work on the stable/unstable front for now, and maybe then take a look at this one again.

  5. engelsman says:

    If someone wants to rename “Module” to “OldModule” would it not be possible
    to do that, and then create an equivalent profile “Module” in zdeprecated whose
    sole purpose was to have “OldModule” as a dependency?

    Maybe needs a little experimentation to see whether this idea would fly :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>