Re: Help with upgrading libflickrnet
Hi Micro,
On Wed, 19 Aug, 2009 at 10:54:49PM +0200, Mirco Bauer wrote:
> > They are not compatible:
> >
> > -----------
> > $$ mono-api-check -2 2.1.5/usr/lib/cli/flickrnet-2.1.5/FlickrNet.dll
> > 2.2/usr/lib/cli/flickrnet-2.2/FlickrNet.dll CLI API Check
> > Assembly Name: FlickrNet
> > Missing Interfaces: 8
> > Additional Interfaces: 63
> >
> > The two assemblies you compared are NOT API compatible!
> > You must use a new package name!
> >
> > The new assembly has additional interfaces. You must raise
> > the minimal version in clilibs!
> >
> > The assembly versions do NOT MATCH!
> > If they are API compatible you MUST generate and install a GAC policy
> > file! -----------
> >
>
> mono-api-check might produce false-positives, to make sure there are
> missing interface that actually cause an ABI breakage use the
> ilcontrast tool from the mono-tools-gui package.
I checked with ilcontrast and if I understand the output correctly,
there are 8 missing interfaces and around 65 new additions. So does
that mean ABI incompatibility?
> > Apart from these changes I also added Conflicts/Replaces the older
> > version 2.1.5 mainly because the symlink
> > /usr/lib/pkgconfig/flickrnet.pc exists in both the packages and dpkg
> > complains while upgrading.
>
> Using Replaces here is good but do _not_ use Conflicts. The point of
> versioning the packages exposing an ABI compatibility would be useless
> if 2 different ABIs could not be installed at the same time. The GAC
> explicitly allows this though! The Replaces will make sure the
> pkg-config file will be replaced with the newer one. We know that this
> is a bit hacky but we have no other solution yet defined in the Debian
> CLI Policy. We plan to add libfoo-cil-dev packages (without any
> version) like the C libs have which would fix the hacky Replaces-only
> solution.
Okay, I too was wondering what is the real use of this symlink, if we
are anyway changing the binary package name. So, using Replaces-only
is the solution and I have done that. Thanks for the explanation.
Hmm.. but, won't the old 2.1.5 binary package be removed from the
archive once we upload this new version, since the source package name
is the same? Could you please point me to some policy page which
explains this upgrade process for binary package name change? I
couldn't find anything on Google.
> > So, what next? Upload to experimental and file bugs to update all
> > rdeps? Should we also provide some transition package 2.1.5-cil
> > depending on 2.2-cil?
>
> Such transition package is useless because the runtime will refuse to
> load the assembly with a different assembly version than the one that
> was linked at compile time (except GAC policy files are used but only
> if the ABI is compatible).
Ok, I understand.
Thanks,
Varun
Reply to: