Migration hint for cgsi-gsoap and lfc?
Hi! grep-excuses says: ellert@debian-wheezy:~$ grep-excuses lfc lfc (1.8.0.1-1 to 1.8.1.2-1) Maintainer: Mattias Ellert 11 days old (needed 10 days) Valid candidate ellert@debian-wheezy:~grep-excuses cgsi-gsoap cgsi-gsoap (1.3.4.0-1 to 1.3.4.2-1) Maintainer: Mattias Ellert 12 days old (needed 10 days) Valid candidate but the migration doesn't seem to happen. The reason listed under more excuses, i.e. that some packages would become uninstallable, doesn't seem to make sense to me. Would it help to hint them together? Mattias signature.asc Description: This is a digitally signed message part
Re: Migration hint for cgsi-gsoap and lfc?
On Fri, 16 Sep 2011 11:33:03 +0200, Mattias Ellert wrote: ellert@debian-wheezy:~$ grep-excuses lfc lfc (1.8.0.1-1 to 1.8.1.2-1) Maintainer: Mattias Ellert 11 days old (needed 10 days) Valid candidate ellert@debian-wheezy:~grep-excuses cgsi-gsoap cgsi-gsoap (1.3.4.0-1 to 1.3.4.2-1) Maintainer: Mattias Ellert 12 days old (needed 10 days) Valid candidate but the migration doesn't seem to happen. The reason listed under more excuses, i.e. that some packages would become uninstallable, doesn't seem to make sense to me. It's perfectly correct. liblcgdm1 (from lfc) and libcgsi-gsoap1 (from cgsi-gsoap) in testing both depend on libvomsapi0, whereas the versions in unstable both depend on libvomsapi1. dpm-mysql-copyd (at least) depends on both liblcgdm1 and libcgsi-gsoap1 so migrating only one of them would result in it indirectly depending on libvomsapi0 and libvomsapi1. In itself that wouldn't be a problem, but for some reason those two libraries conflict. Would it help to hint them together? Probably. What would help more would be not having the library packages conflict. The fact that libvomsapi1 both Conflicts and Replaces libvomsapi0 suggests that you're doing it wrong[tm]. Specifically, the issue seems to be that the packages both contain things like /usr/share/voms/vomses.template and /etc/vomses. Those seem like things that really shouldn't be in a shared library package. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1b6283947da9d15043547df91a11e...@adsl.funky-badger.org
Re: Migration hint for cgsi-gsoap and lfc?
fre 2011-09-16 klockan 11:34 +0100 skrev Adam D. Barratt: On Fri, 16 Sep 2011 11:33:03 +0200, Mattias Ellert wrote: ellert@debian-wheezy:~$ grep-excuses lfc lfc (1.8.0.1-1 to 1.8.1.2-1) Maintainer: Mattias Ellert 11 days old (needed 10 days) Valid candidate ellert@debian-wheezy:~grep-excuses cgsi-gsoap cgsi-gsoap (1.3.4.0-1 to 1.3.4.2-1) Maintainer: Mattias Ellert 12 days old (needed 10 days) Valid candidate but the migration doesn't seem to happen. The reason listed under more excuses, i.e. that some packages would become uninstallable, doesn't seem to make sense to me. It's perfectly correct. liblcgdm1 (from lfc) and libcgsi-gsoap1 (from cgsi-gsoap) in testing both depend on libvomsapi0, whereas the versions in unstable both depend on libvomsapi1. dpm-mysql-copyd (at least) depends on both liblcgdm1 and libcgsi-gsoap1 so migrating only one of them would result in it indirectly depending on libvomsapi0 and libvomsapi1. In itself that wouldn't be a problem, but for some reason those two libraries conflict. Would it help to hint them together? Probably. What would help more would be not having the library packages conflict. The fact that libvomsapi1 both Conflicts and Replaces libvomsapi0 suggests that you're doing it wrong[tm]. Specifically, the issue seems to be that the packages both contain things like /usr/share/voms/vomses.template and /etc/vomses. Those seem like things that really shouldn't be in a shared library package. Regards, Adam libvomsapi0 is orphan - it is no longer built by any source package. According the the documentation http://www.debian.org/doc/manuals/developers-reference/pkgs.html#removing-pkgs such packages are supposed to be removed automatically, and filing a removal request should not be necessary. I don't really understand why it is still there in testing, I expected it to have been removed when the new voms package migrated to testing. On the other hand, I didn't expect that the voms package would migrate before all packages that depended on libvomsapi0 had been rebuilt and no longer had this dependency, and that then all these packages would then migrate together. It seems there are details in how migration works that I don't fully understand. Mattias signature.asc Description: This is a digitally signed message part
Re: Migration hint for cgsi-gsoap and lfc?
On Fri, 16 Sep 2011 15:36:21 +0200, Mattias Ellert wrote: fre 2011-09-16 klockan 11:34 +0100 skrev Adam D. Barratt: In itself that wouldn't be a problem, but for some reason those two libraries conflict. [...] Specifically, the issue seems to be that the packages both contain things like /usr/share/voms/vomses.template and /etc/vomses. Those seem like things that really shouldn't be in a shared library package. [...] libvomsapi0 is orphan - it is no longer built by any source package. According the the documentation http://www.debian.org/doc/manuals/developers-reference/pkgs.html#removing-pkgs such packages are supposed to be removed automatically, and filing a removal request should not be necessary. No removal request is necessary; apologies if my mail somehow gave that impression. However, that's largely irrelevant to my point - why do you have files in libvoms* that _do not belong in library packages_? It should be possible to have libvomsapi0 and libvomsapi1 be co-installable, which would have meant everything would have migrated on its own. In fact, the current situation is an RC bug in voms - the rationale provided in Policy 8.1 for the must directive on changing shared library package names when SONAME changes is that it: allows several versions of the shared library to be installed at the same time, allowing installation of the new version of the shared library without immediately breaking binaries that depend on the old version. and 8.2 goes further: If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Otherwise, several versions of the shared library cannot be installed at the same time without filename clashes, making upgrades and transitions unnecessarily difficult. I don't really understand why it is still there in testing, I expected it to have been removed when the new voms package migrated to testing. On the other hand, I didn't expect that the voms package would migrate before all packages that depended on libvomsapi0 had been rebuilt and no longer had this dependency, and that then all these packages would then migrate together. It seems there are details in how migration works that I don't fully understand. To be fair, this is a fairly recent change to the migration process and not well document as yet. However, if the issues described in my previous mail and above did not exist then the packages would have all migrated together in any case. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f01c0117230d9f05e9031ac176f69...@adsl.funky-badger.org
