[Pkg-mono-devel] maintaining older version of cil libraries

[Mirco Bauer]

Hi Sam,

On Thu, 2008-01-03 at 10:00 +0000, Sam Clegg wrote:
> Yesterday I uploaded a new version of boo (0.8.0) to unstable.

Nice :)

> However, there is at least one package which broke due to assembly
> version changing from 1.0.0.0 to 2.0.0.0:
> 
> http://bugs.debian.org/458835

Uh not nice :)

> 
> Of course, this could have been avoided if I had just run apt-rdepends
> first :)

Updating to newer version is allright, but ABI/API compatible must be
checked, if they are not ABI/API compatible then you must reflect that
in the packages.

> 
> I was just wondering what the correct course of action is to fix this.

To be honest, boo wasn't never correct packaged, it is and was always
unversioned, means with any ABI breakage (with happened already like 2
or 3 times) it breaks all other packages in debian using it.

The Debian CLI Policy [0] requires for that reason that all libraries
used by other packages to be _versioned_ [1] that means:
a) package name needs to reflect the ABI version (first 2 number parts
of the assembly version)
b) the library is signed using a strong key (sn) and always be signed
with the same key from that point on, else it's an ABI breakage
c) if upstream bumps the assembly version and the version is compatible
(tested with mono-api-check) then a GAC policy files [2] must be
installed, else it's also an ABI breakage.

Any ABI breakage means always a new package name, but be warned
mono-api-check might spit out false positives :)

> 
> My initial plan is to create both boo1 and boo2 source packages
> and build the old package 'boo' from the boo1 sources.  This would fix
> the current banshee packages (which depends on boo (>= 0.7.6.2237) to
> access the boo 1.0 libs).

Well the question is, if thats really needed. I don't think Boo broke
API, but just ABI. So a recompile of banshee should fix it.
It would only be a problem for applications that targets CLI 1.0 and
wants to use the boo 0.8.0, that would not work now, but I don't know
any CLI 1.0 application in debian that uses boo, most applications moved
to CLI 2.0 already AFAIK.

> 
> Next I would create both libboo2.0-cil and boo2 from the boo2 sources,
> which means that in the future packages such as banshee would end up
> depending on libbooX-cil and this kind of problem shouldn't occur again.

Thats the important feature of versioning.

> 
> Does this make sense?

Versioning, yes, it's even required by the Debian CLI Policy :)
But if you need 2 source package to archive _future_ ABI stability in
debian of boo, I don't think thats currently needed.

> 
> I am also planning on uploading boo/debian and boo/debian
> to the pkg-mono repository and moving maintainership to the pkg-mono
> group.

Please import the source package of boo to:
svn+ssh://svn.debian.org/svn/pkg-cli-libs/packages/boo

That way we can review the packages easiy before you upload them :)

It's not pkg-mono btw, as that's for maintaining the Mono platform, we
made pkg-cli-libs and pkg-cli-apps for the rest.

[0] http://pkg-mono.alioth.debian.org/cli-policy/
[1] http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning
[2] http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-policy-files

-- 
Regards,

Mirco 'meebey' Bauer

PGP-Key ID: 0xEEF946C8

FOSS Developer    meebey at meebey.net  http://www.meebey.net/
PEAR Developer    meebey at php.net     http://pear.php.net/
Debian Developer  meebey at debian.org  http://www.debian.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-mono-devel/attachments/20080103/bd01c67f/attachment.pgp