| Synopsis: This policy governs the various steps needed to remove a package from the distribution. |
Contents
Marking the package as obsolete in the subversion repository
Each package in the distribution lives in its own directory in the package subversion repository, which is branched for each release. For instance, the openssh packages is in svn+ssh://svn.mageia.org/svn/packages/cauldron/openssh.
Once a package is removed, this directory should not get deleted, but moved in the obsolete directory. For instance, the xemacs package directory is now in svn+ssh://svn.mageia.org/svn/packages/obsolete/xemacs.
This change can be done either with any subversion client:
svn mv svn+ssh://svn.mageia.org/svn/packages/cauldron/foo svn+ssh://svn.mageia.org/svn/packages/obsolete/foo -m "SILENT: mark foo package as obsolete"
or with mgarepo tool:
mgarepo obsolete foo -m "SILENT: mark foo package as obsolete"
Checking out a package from obsolete in the subversion repository
To checkout a package from obsoletes (for testing in the future maybe) you can use:
svn co svn+ssh://svn.mageia.org/svn/packages/obsolete/<package>/current <package>
Marking the package as unmaintained
With mgarepo tool:
mgarepo maintdb set foo nobody
Forcing package removal on users machines (optional)
Depending of the reason for which a package is removed, it may be needed to force its removal from user machines upon update:
- a package replaced by another one with similar features must be explicitly obsoleted by the new package: if the package bar replaces package foo, the bar package has to obsolete package foo.
- a package removed for any other reason may be obsoleted by the dedicated task-obsolete package: if the package bar is removed without any specific replacement, the task-obsolete package may obsolete foo.
Whatever package carry the Obsolete tag, the following applies:
- all binary packages produced from a single source package (ie lib64fooXXX, libfooXXX, python3-foo, etc...) must be explicitly obsoleted
- obsoleting the source package itself is not required, but doesn't hurt
- explicit versioning, including Epoch if needed, is required
For instance, to obsolete the foo package, producing a library subpackage with major version number 1, starting from its current version 3 and release 1:
Obsolete: foo < 3-2 Obsolete: lib64foo1 < 3-2 Obsolete: libfoo1 < 3-2 Obsolete: lib64foo-devel < 3-2 Obsolete: libfoo-devel < 3-2
Deleting the files from distribution mirrors
If an obsolete tag has been used in another package, the upload process should automatically handle cleaning of old files once obsoleting package is submitted.
If not, an explicit mail must be send to sysadmins, with an explicit list of filenames to remove. Only source packages need to be mentioned, tough, corresponding binaries should be deleted automatically.
Removing from rpmsrate
If the package or any of its subpackages are listed in the rpmsrate.raw file in the meta-task package, remove those references.
