[Rpm-maint] splitting packages

Ales Kozumplik akozumpl at redhat.com
Mon Jul 7 13:56:57 UTC 2014

During our IRC discussion today we arrived at a couple of possible 
solutions to this. Without proposing any one in particular yet (but 
ideologically leaning towards the dynamic dep language), here's a summary:



On 06/30/2014 03:52 PM, Ales Kozumplik wrote:
> Hello people,
> this is about [1], i.e. the fact that DNF currently doesn't support an
> upgrade path where a package is split into several new packages. It
> would be better suited for yum-devel but I'm posting it here since
> Michael doesn't read yum-devel.
> There are two approaches to this out there that I know of: the Fedora
> way where N new packages obsolete the old package [2] [3]. When Yum sees
> this during 'yum upgrade' it installs all the N new pacakges and removes
> the old one. Note that the Fedora guidelines and even the Yum manual
> page are quite vague on the exact semantics of how splitting and
> renaming works. I'd be interested to find a better description somewhere.
> There is a different convention used in SUSE [4] that employs a special
> 'split-alias' provide. Michael said in the bugzilla this is not a
> desirable approach.
> Before I try to come up with a proposal on fixing this, does somebody
> have a proposal at hand? Could supplements: or similar help? Are there
> reasons to move away from what Yum does (besides that using 'obsoletes:'
> is a bit random thing for it, i.e. I imagine it was more picked because
> it didn't break anything else in the RPM world than picked as a design
> decision)?
> Ales
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1107973
> [2]
> http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages#Binary_package_naming_changes
> [3] https://fedoraproject.org/wiki/Packaging:Conflicts#Splitting_Packages
> [4]
> http://en.opensuse.org/openSUSE:Package_dependencies#Splitting_a_package_into_two
> _______________________________________________
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint

More information about the Rpm-maint mailing list