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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
