PackagingDrafts/RenamingPackages

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Changelog

0.1: Initial draft

Existing Guideline

Treat Packages as new packages and have a full Review. Followed by marking the old package dead in cvs and following EOL policy.

Proposed Guideline

Packages are sometimes renamed, either by upstream action or locally in the collection to more closely match NamingGuidelines. This policy explains the procedure for renaming packages.

• The maintainer of the package that is to be renamed will create spec files and src.rpms with the new name and the needed Provides/Obsoletes based on Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages

• Links to this proposed renamed package will be posted to the fedora-devel mailing list for inspection of the development community.

• Once approved by another package maintainer, the package maintainer can request CVS for the newly named module citing the mailing list post approval.

• Once the new package has been imported, the maintainer should use the PackageMaintainers/PackageEndOfLife procedure on the old package.

Pages which will need changes

• Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages
• PackageMaintainers/CVSAdminProcedure
• PackageMaintainers/Policy

Discussion

• Should a re-review be required instead of just a mailing list approval?
• Given how often people get the provides/obsoletes wrong is just one approval on the list enough?
• Should approval come from provenpackagers or some other group? Or is maintainers enough?
• There needs to be a way to handle mass renames that does not depend on each individual packager concerned by the rename initiating the renaming himself.

- I think Obsoletes/Provides check or so is needed and re-review is more proper than approval on mailing list. Anyway I don't think reapproval will take long if the original spec file was in good shape - Mamoru