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:

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.

Example:
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:

Copy the module to it’s new place and rename the copy.e.g: cp -rva compilers/gcc compilers/newgcc

5 Responses to Handling renamed modules – An idea

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.

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.

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.

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.

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