Description of problem: Transaction check error: file /usr/share/locale/cs/LC_MESSAGES/phodav.mo from install of libphodav-2.0-2.0-1.fc23.x86_64 conflicts with file from package libphodav-1.0-0.4-5.fc22.x86_64 file /usr/share/locale/hu/LC_MESSAGES/phodav.mo from install of libphodav-2.0-2.0-1.fc23.x86_64 conflicts with file from package libphodav-1.0-0.4-5.fc22.x86_64 That's clearly a missing obsoletes in libphodav-2.0, and I am not even sure that's compliant from a packaging point of view.
(In reply to Michael Scherer from comment #0) > Description of problem: > > Transaction check error: > file /usr/share/locale/cs/LC_MESSAGES/phodav.mo from install of > libphodav-2.0-2.0-1.fc23.x86_64 conflicts with file from package > libphodav-1.0-0.4-5.fc22.x86_64 > file /usr/share/locale/hu/LC_MESSAGES/phodav.mo from install of > libphodav-2.0-2.0-1.fc23.x86_64 conflicts with file from package > libphodav-1.0-0.4-5.fc22.x86_64 > Hmm, I guess the po file should be versionized too > That's clearly a missing obsoletes in libphodav-2.0, and I am not even sure > that's compliant from a packaging point of view. I don't know what you are talking about. Can you help me?
Created attachment 995019 [details] Fix libphodav* naming I think Michael is suggesting something like the attached patch. I haven't tested it at all (it builds), one would need to test the various upgrades situations... (from current rawhide to this package, and from f21 with older phodav and spice-gtk to this package and rebuilt spice-gtk)
Created attachment 1006295 [details] updated patch This patch fixes a missing s/phodav2/phodav in the requires/description of the -devel package, and had versioning to the compat requires/obsoletes. I've done some manual testing, and the upgrade of went as expected (older phodav packages removed/newer installed). I'd get this in rawhide for more testing/refining
phodav2 should be parellel installable with phodav (1). I don't get your changes: why do you remove a patch that is correcting the path? (it's also in upstream btw) The current version in dist-git/rawhide looks correct to me now.
(In reply to Marc-Andre Lureau from comment #4) > phodav2 should be parellel installable with phodav (1). Why? This is almost never done in fedora, except when there is a strong requirement to keep the older version of the library around. I think when this is done, you end up with 2 dist-git repos, phodav and phodav2. So no, I don't think the way it's currently done in rawhide is correct at all.
(In reply to Christophe Fergeau from comment #5) > (In reply to Marc-Andre Lureau from comment #4) > > phodav2 should be parellel installable with phodav (1). > > Why? This is almost never done in fedora, except when there is a strong > requirement to keep the older version of the library around. I think when > this is done, you end up with 2 dist-git repos, phodav and phodav2. So no, I > don't think the way it's currently done in rawhide is correct at all. Ok, so I suppose it's missing just a few Obsolete: libphodav-1.0{-devel}, isn't it?
(In reply to Marc-Andre Lureau from comment #6) > Ok, so I suppose it's missing just a few Obsolete: libphodav-1.0{-devel}, > isn't it? + Obsoletes/Provides for the various names this package had in rawhide This is what this patch is doing.
(In reply to Christophe Fergeau from comment #7) > (In reply to Marc-Andre Lureau from comment #6) > > Ok, so I suppose it's missing just a few Obsolete: libphodav-1.0{-devel}, > > isn't it? > > + Obsoletes/Provides for the various names this package had in rawhide If you want to make rawhide somehow a bit stable, I don't think it's mandatory to do that, just because a build introduced wrong names. > This is what this patch is doing. No, you also remove a patch that is now upstream and change the name of library to not follow soname. I'd rather keep it the way it is now with soname version libphodav2.
(In reply to Marc-Andre Lureau from comment #8) > (In reply to Christophe Fergeau from comment #7) > > (In reply to Marc-Andre Lureau from comment #6) > > > Ok, so I suppose it's missing just a few Obsolete: libphodav-1.0{-devel}, > > > isn't it? > > > > + Obsoletes/Provides for the various names this package had in rawhide > > If you want to make rawhide somehow a bit stable, I don't think it's > mandatory to do that, just because a build introduced wrong names. > If you don't do that, upgrades will be broken for people who happen to have libphodav-2.0-devel or libphodav2-devel installed when they run yum update. > > This is what this patch is doing. > > No, you also remove a patch that is now upstream I don't think having/not having this patch matters much. It was introduced to make it easier to parallel install phodav1 and phodav2, but with this patch they won't be installed in parallel. The new paths will quietly be reintroduced when a new version of phodav is released, and the doc/translation directories will be renamed appropriately by rpm (after a small update to the .spec). > and change the name of > library to not follow soname. I'd rather keep it the way it is now with > soname version libphodav2. If you are talking about the naming of the package, I don't think this is a good idea to have it include the soname (and this is quite unusual). I believe this is kind of covered in https://fedoraproject.org/wiki/Packaging:NamingGuidelines#MultiplePackages A package named libphodav2 would be a compat version of the libphodav package, which is not the case here. Having the soname in the package name also means you'll need to do add Obsoletes every time upstream breaks ABI. The soname is already automatically included in one of the provides once the package is built: $ rpm -q -provides libphodav-2.0 libphodav-2.0.so.0(LIBPHODAV1_0.0)(64bit)
(In reply to Christophe Fergeau from comment #9) > If you don't do that, upgrades will be broken for people who happen to have > libphodav-2.0-devel or libphodav2-devel installed when they run yum update. I get that, but I think rawhide is an unstable place by its nature. > I don't think having/not having this patch matters much. It was introduced > to make it easier to parallel install phodav1 and phodav2, but with this > patch they won't be installed in parallel. The new paths will quietly be > reintroduced when a new version of phodav is released, and the > doc/translation directories will be renamed appropriately by rpm (after a > small update to the .spec). Let's keep that patch with the new directories. > > and change the name of > > library to not follow soname. I'd rather keep it the way it is now with > > soname version libphodav2. > > If you are talking about the naming of the package, I don't think this is a > good idea to have it include the soname (and this is quite unusual). I > believe this is kind of covered in It is rather usual judging by the packages on my f21. > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#MultiplePackages > A package named libphodav2 would be a compat version of the libphodav > package, which is not the case here. Having the soname in the package name > also means you'll need to do add Obsoletes every time upstream breaks ABI. Well, I would rather let yum figure orphan dependencies (yum autoremove). I am not sure the Obsolete are even required here.
(In reply to Marc-Andre Lureau from comment #10) > (In reply to Christophe Fergeau from comment #9) > > If you don't do that, upgrades will be broken for people who happen to have > > libphodav-2.0-devel or libphodav2-devel installed when they run yum update. > > I get that, but I think rawhide is an unstable place by its nature. This does not mean it's ok to break it even more. > > > I don't think having/not having this patch matters much. It was introduced > > to make it easier to parallel install phodav1 and phodav2, but with this > > patch they won't be installed in parallel. The new paths will quietly be > > reintroduced when a new version of phodav is released, and the > > doc/translation directories will be renamed appropriately by rpm (after a > > small update to the .spec). > > Let's keep that patch with the new directories. Ok. > > > > and change the name of > > > library to not follow soname. I'd rather keep it the way it is now with > > > soname version libphodav2. > > > > If you are talking about the naming of the package, I don't think this is a > > good idea to have it include the soname (and this is quite unusual). I > > believe this is kind of covered in > > It is rather usual judging by the packages on my f21. $ rpm -qa |grep ^lib[^-]*[0-9]- |grep -v -- "-devel" | wc -l 54 $ rpm -qa |grep ^lib[^-]*[^0-9]- |grep -v -- "-devel" | wc -l 498 So 10% of the libraries on that system, and a significant portion of these are false positives > > > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#MultiplePackages > > A package named libphodav2 would be a compat version of the libphodav > > package, which is not the case here. Having the soname in the package name > > also means you'll need to do add Obsoletes every time upstream breaks ABI. > > Well, I would rather let yum figure orphan dependencies (yum autoremove). I > am not sure the Obsolete are even required here. This is one way of handling this, and was done this way in mandriva, but this is not how things are done in Fedora.
(In reply to Christophe Fergeau from comment #11) > > Well, I would rather let yum figure orphan dependencies (yum autoremove). I > > am not sure the Obsolete are even required here. > > This is one way of handling this, and was done this way in mandriva, but > this is not how things are done in Fedora. Ok, so to avoid churning this even more, I would add only the relevant Obsolete lines to make update clean the old lib and help with the rawhide changes.
(In reply to Marc-Andre Lureau from comment #12) > (In reply to Christophe Fergeau from comment #11) > > > Well, I would rather let yum figure orphan dependencies (yum autoremove). I > > > am not sure the Obsolete are even required here. > > > > This is one way of handling this, and was done this way in mandriva, but > > this is not how things are done in Fedora. > > Ok, so to avoid churning this even more, I would add only the relevant > Obsolete lines to make update clean the old lib and help with the rawhide > changes. If we add Obsoletes/Provides: libphodav-2.0 to help with rawhide upgrades, I'd go the extra mile and add a one more set of Obsoletes/Provides to correctly name the package rather than having it named libphodav2 forever.
(In reply to Christophe Fergeau from comment #13) > If we add Obsoletes/Provides: libphodav-2.0 to help with rawhide upgrades, > I'd go the extra mile and add a one more set of Obsoletes/Provides to > correctly name the package rather than having it named libphodav2 forever. Why not keep libphodav2 name? 10% of packages use version too. Please don't change this again. I don't think we need Provides lines
(In reply to Marc-Andre Lureau from comment #14) > (In reply to Christophe Fergeau from comment #13) > > If we add Obsoletes/Provides: libphodav-2.0 to help with rawhide upgrades, > > I'd go the extra mile and add a one more set of Obsoletes/Provides to > > correctly name the package rather than having it named libphodav2 forever. > > Why not keep libphodav2 name? Just that libphodav2-5.3 shipping a libphodav.so.5 file will be weird. Given that the work is already done to use the correct name, this would fix everything at once. > 10% of packages use version too. _At most_ 10%, too lazy to remove the false positives which match the upstream name (libx11, libieee1394), and the actual compat packages (glib2, libpng*, ...) > I don't think we need Provides lines https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
(In reply to Christophe Fergeau from comment #15) > > Why not keep libphodav2 name? > > Just that libphodav2-5.3 shipping a libphodav.so.5 file will be weird. Given > that the work is already done to use the correct name, this would fix > everything at once. Eh? It's actually: /usr/lib64/libphodav-2.0.so.0 > > I don't think we need Provides lines > > https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming. > 2FReplacing_Existing_Packages "If a package is being renamed without any functional changes, or is a compatible enough replacement" It's not compatible. The ABI/API changed. The soname changed etc.
(In reply to Marc-Andre Lureau from comment #16) > (In reply to Christophe Fergeau from comment #15) > > > Why not keep libphodav2 name? > > > > Just that libphodav2-5.3 shipping a libphodav.so.5 file will be weird. Given > > that the work is already done to use the correct name, this would fix > > everything at once. > Eh? It's actually: > /usr/lib64/libphodav-2.0.so.0 Make that "libphodav2-5.3-1.x86_64.rpm shipping a libphodav-5.0.so.0 will be weird" then. If you are happy with keeping the libphodav2 name for the package forever, the name can indeed be kept. > > > > I don't think we need Provides lines > > > > https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming. > > 2FReplacing_Existing_Packages > > "If a package is being renamed without any functional changes, or is a > compatible enough replacement" > > It's not compatible. The ABI/API changed. The soname changed etc. Context is: (In reply to Marc-Andre Lureau from comment #14) > (In reply to Christophe Fergeau from comment #13) > > If we add Obsoletes/Provides: libphodav-2.0 to help with rawhide upgrades, > > [...] > [...]I don't think we need Provides lines The patch does not have a Provides for the -1.0 version.
(In reply to Christophe Fergeau from comment #17) > Make that "libphodav2-5.3-1.x86_64.rpm shipping a libphodav-5.0.so.0 will be > weird" then. If you are happy with keeping the libphodav2 name for the > package forever, the name can indeed be kept. I intend to keep bumping changing the name to follow upstream (hopefully it doesn't happen too often). > The patch does not have a Provides for the -1.0 version. And? "It's not compatible. The ABI/API changed. The soname changed etc"
(In reply to Marc-Andre Lureau from comment #18) > (In reply to Christophe Fergeau from comment #17) > > Make that "libphodav2-5.3-1.x86_64.rpm shipping a libphodav-5.0.so.0 will be > > weird" then. If you are happy with keeping the libphodav2 name for the > > package forever, the name can indeed be kept. > > I intend to keep bumping changing the name to follow upstream (hopefully it > doesn't happen too often). What is the benefit of keeping the soname in the package name and changing it now and then? This makes more work overall (soname bump means %files change, subpackage name change, additional Obsoletes to add, need to change the BuildRequires name in all users, ...). If you set the package name to libphodav, you need to do the work above once (now), and then when the soname changes, you only need to change %files.
(In reply to Christophe Fergeau from comment #19) > What is the benefit of keeping the soname in the package name and changing > it now and then? Make an API break and to make it possible to install in parallel older version.
(In reply to Marc-Andre Lureau from comment #20) > (In reply to Christophe Fergeau from comment #19) > > What is the benefit of keeping the soname in the package name and changing > > it now and then? > > Make an API break and to make it possible to install in parallel older > version. What for? The older version is not going to be maintained anyway and only the latest version will be present in the repositories.
(In reply to Christophe Fergeau from comment #21) > What for? The older version is not going to be maintained anyway and only > the latest version will be present in the repositories. In practice, for phodav it's probably not that useful since there is only a single known user. But in theory, don't you want to keep older users compatibility? And how do you express a BuildRequires that will not break when the dependency API breaks? If spice-gtk depends on say a libphodav, that will break if library bump to -3.0 for API break. All in all, I am just reflecting in package name the best practices in upstream library naming when breaking things.
(In reply to Marc-Andre Lureau from comment #22) > (In reply to Christophe Fergeau from comment #21) > > What for? The older version is not going to be maintained anyway and only > > the latest version will be present in the repositories. > > In practice, for phodav it's probably not that useful since there is only a > single known user. But in theory, don't you want to keep older users > compatibility? 90+% of the library packages do not care about that... The day parallel-installable versions of phodav are needed, you'll need to add a second phodav repository to dist-git with a different name anyway... > > And how do you express a BuildRequires that will not break when the > dependency API breaks? If spice-gtk depends on say a libphodav, that will > break if library bump to -3.0 for API break. All in all, I am just > reflecting in package name the best practices in upstream library naming > when breaking things. If you break ABI, you'll need to rebuild dependent packages regardless of if the API is broken or not (broken API implies broken ABI, but the opposite is not necessarily true). With a versioned name in the .spec, you'll have to update the .spec to pick the new -devel package, then fix the build. With a generic libphodav-devel, the rebuild will fail, so you'll have to fix the build. If you want rpmbuild to complain before the compilation fails, nothing prevents you from specifying BuildRequires: libphodav-devel < 3.0 All in all, this looks like more complications for not much gain (in addition to being unusual for a fedora package).
(In reply to Christophe Fergeau from comment #23) > 90+% of the library packages do not care about that... The day > parallel-installable versions of phodav are needed, you'll need to add a > second phodav repository to dist-git with a different name anyway... > > I must be one of the 10% who cares. And since there is a single version in Fedora at this point, I don't think we need a seperate dist-git. But I still have both -1.0 and 2.0 happily installed in parallel here for development (that way I can use/build latest spice-gtk and f21 too) > > And how do you express a BuildRequires that will not break when the > > dependency API breaks? If spice-gtk depends on say a libphodav, that will > > break if library bump to -3.0 for API break. All in all, I am just > > reflecting in package name the best practices in upstream library naming > > when breaking things. > > > If you break ABI, you'll need to rebuild dependent packages regardless of if > the API is broken or not (broken API implies broken ABI, but the opposite is Older version still build with older API. > not necessarily true). With a versioned name in the .spec, you'll have to > update the .spec to pick the new -devel package, then fix the build. With a > generic libphodav-devel, the rebuild will fail, so you'll have to fix the > build. If you want rpmbuild to complain before the compilation fails, > nothing prevents you from specifying BuildRequires: libphodav-devel < 3.0 But that won't work since you can't have both version installed in parallel. > All in all, this looks like more complications for not much gain (in > addition to being unusual for a fedora package). It's not that much complication to me, the contrary however feels more confusing, so I would rather keep package with the version scheme
(In reply to Marc-Andre Lureau from comment #24) > I must be one of the 10% who cares. And since there is a single version in > Fedora at this point, I don't think we need a seperate dist-git. But I still > have both -1.0 and 2.0 happily installed in parallel Which only is possiblel because so far phodav hasn't been following https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages and does not have the required Obsoletes...
(In reply to Christophe Fergeau from comment #25) > Which only is possiblel because so far phodav hasn't been following > https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming. > 2FReplacing_Existing_Packages and does not have the required Obsoletes... "In the event that it becomes necessary to rename or replace an existing package, the new package should make the change transparent" First of all, it's not replace nor rename to me, it's a different version, you can use both in parallel, and I want that as I explained. Then, it is a "should" not a "must". Finally, the update is going to be transparent without other change. So, I would not even use Obsolete here, and I think the bug can be closed with the last build.
(In reply to Marc-Andre Lureau from comment #26) > > First of all, it's not replace nor rename to me, it's a different version, libphodav2-2.0-1 VS libphodav3-3.0-1 libphodav2/libphodav3 is the name, 2.0/3.0 is the version, 1 is the release, so no, in the context of fedora packages it's not 'a different version' > you can use both in parallel, and I want that as I explained. Honestly, parallel installation is useless to fedora users, and not having the Obsoletes will just cause old packages lying around on users' hard drive for no good reasons.
I wish the rules for packaging a library when breaking API&ABI and bumping version would be stated more clearly. If the policy in Fedora is to not do parellel installable versions of a library in general (that's unfortunate to me), then I understand the rationale for renaming to "libphodav" without version suffix. Too bad I have never been said that during review of other of my packages (libgcab1, libmsi1..) When library update breaks ABI/API, that is likely a bad idea, as (at least) BuildRequires will fail to check correct deps. Since I have Debian background, that's also why I have come to believe that naming after the soname was the best practice. But if Fedora recommends differently, for whatever reason, then I will keep complaining elsewhere! (or just switch distribution) However, I don't think this really matters so much that people actually care, and if you wouldn't be using rawhide where some files conflicted during update, you wouldn't probably notice and care that the version changed. despite my disappointment, do what you think is best, I don't know enough of Fedora rules.
Created attachment 1006812 [details] New version keeping the versioned gtk-doc/po patch Thanks. What Debian does seems similar to what we were doing in Mandriva. Fedora tends to try to always use the latest version of a library, I think both have approaches have pros and cons. This updated patch keeps the versioned gtk-doc directory/mo file names.
I've built this in rawhide and f22 now.