Re: Help with upgrading libflickrnet
Hi Varun,
On Thu, 20 Aug 2009 21:51:56 -0400
Varun Hiremath <varun@debian.org> wrote:
> Hi Micro,
I am not that small *cough*
>
> 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?
Yes
>
> > > 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?
Yes, the archive admins are regularly running cleanup processes that
will remove binary packages that are not build by and source package.
This is expected and still will allow a smooth upgrade path for all
users that have the old version installed and now can install the new
version without the need of waiting for a completed transition.
Renaming a library package introduces implicitly a transition, all
rdeps have to be rebuild (and updated build-deps in our case).
> 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.
That's a good question, I don't know any that covers the library
transitioning part. The simple rename case is described here though:
http://www.debian.org/doc/developers-reference/pkgs.html#s5.9.3
>
> > > 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
--
Regards,
Mirco 'meebey' Bauer
PGP-Key ID: 0xEEF946C8
FOSS Developer meebey@meebey.net http://www.meebey.net/
PEAR Developer meebey@php.net http://pear.php.net/
Debian Developer meebey@debian.org http://www.debian.org/
Reply to: