[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help with upgrading libflickrnet



Hi Jo,

On Fri, 14 Aug, 2009 at 11:45:47AM +0100, Jo Shields wrote:
> On Fri, 2009-08-14 at 12:17 +0200, Mirco Bauer wrote:
> > > - should I rename source package and let the older version also
> > > co-exist?
> 
> If nothing is gained by doing so, then I would recommend against it -
> it's just more work to maintain
> 
> > > - how do I check for ABI/API compatibility with the older version?
> 
> Try "mono-api-check -2 /path/to/old.dll /path/to/new.dll". It'll give
> you a simple answer to the ABI question (are there any removed
> methods/properties/etc? No means compatible). If it's compatible, then
> there's even less need to ship an old version - include a Policy file
> (http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-policy-files) so any app compiled against 2.1.5 still works.

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!
-----------

> > > - should the binary package be named *2.2.0-cli or just *2.2-cli?
> 
> This is covered in policy -
> http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning - and basically comes down to "2.2-cil"

Okay, I have fixed this.

> 
> > > I actually have prepared a preliminary package, which is available on
> > > my homepage [4].
> > > Could you please have a look at the package, and let
> > > me know your comments?
> 
> debian/changelog:
> * Renaming the source package seems pretty pointless to me - there are
> very few rdeps, so even if it's not ABI compatible, little is served by
> it
> * Redo the numbering system, it sucks. I discussed this with meebey a
> few days ago, and we felt that a "normal" version number, with an epoch,
> was easiest for users and developers to understand - meaning
> "1:2.2.0-1". 48055~2.2.0-1 doesn't really mean anything to anyone, as
> it's unclear to casual observers that 48055 is a SVN revision - and the
> "~" usually means "before" so it doesn't make much sense
> 

Sorry, this was my mistake while preparing the first package. I
thought upstream were using svn version for releases.. but I have
fixed it now using an epoch.

> debian/control:
> * See above r.e. binary package name/number

ok, fixed.

> 
> debian/copyright:
> * If you really want to make a new source package, be sure to refresh
> this - e.g. the download link is to the previous version

updated.

> 
> debian/installcligac:
> * See above r.e. binary package name/number

fixed.

> 
> debian/watch:
> * I've sent a query to someone at CodePlex to try and make this
> manageable - nothing yet though

okay, thanks.

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.

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?

I have committed my changes to pkg-cli-libs svn and new package in
available on my homepage [1].

Thanks for your comments.

-Varun

[1] http://people.debian.org/~varun/


Reply to: