Advice request for mono packages

[Toshio Kuratomi]

Tom "spot" Callaway wrote:
> On Tue, 2008-09-16 at 13:29 +0100, Paul wrote:
>> It is something which is important for mono based packages that
>> provide
>> the source for non-GAC dlls and needs to be addressed in the packaging
>> guidelines (something which needs altering a tad IMHO).
> 
> This is really where we're working around bad coding practices from
> upstream. 
> 
> Why doesn't Mono.Cecil adopt a stable API? Or at least a versioned API,
> so that when they break API, they increment version and then things can
> depend on a version of the API?
> 
> This isn't rocket science. It isn't even novel.
> 
> We don't generally permit package-local copies of system libraries for
> lots of reasons, like the fact that they often miss bug fixes, security
> fixes, often end up being duplicated in multiple packages and are much
> more difficult to maintain.
> 
If we have to I would be much more in favour of separate versioned
package libraries in cases like these than having separate library
versions in multiple application libraries.  This means that when a
security fix comes out, we can look at package names and decide we need
to upgrade Mono.Cecil-1.0 to 1.0.1 and backport a fix to
Mono-Cecil-0.9.1 instead of hunting on the filesystem for anything with
a Mono.Cecil dll.

Several notes to this:
To make this work, upstreams for the dlls need to version their APIs as
spot mentions.

There is increased packager burden as packagers have to maintain
multiple mono.cecil packages *and* may have to perform backports to old
versions of the library that upstream no longer supports.

Traditionally, we have worked on the application source to make it
compile/run with newer versions of the API in strong preference to
making compatible library packages.  This should continue to be the case
as we're either going to end up writing code to backport fixes to the
dead-upstream-versions of the dlls or writing code to bring living
applications up to speed with the newest versions of the libraries.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080916/1a1566ed/attachment.sig>