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
Specifically, the issue seems to be that the packages both contain
things like "/usr/share/voms/vomses.template" and "/etc/vomses".
seem like things that really shouldn't be in a shared library
libvomsapi0 is orphan - it is no longer built by any source package.
According the the documentation
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
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
same time, allowing installation of the new version of the shared
library without immediately breaking binaries that depend on the
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
the shared library package. Otherwise, several versions of the
library cannot be installed at the same time without filename
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
before all packages that depended on libvomsapi0 had been rebuilt and
longer had this dependency, and that then all these packages would
migrate together. It seems there are details in how migration works
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.