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

Library packages: co-installability, build-depends, transitions



In my previous mail I talked about some ideas to ease transitions. I've
thought over this a bit more and come up with several different
approaches which could  be used. Here is a list with their pros (+) and
cons (-). Bear in mind that in all cases most of the work will be done
for you by javahelper.

In the list below when I say "version" I mean "API version" not
"upstream release version". API version changes when upstream change the
API and is encoded in the package name.

Which of these options do people think are acceptable / preferred?

No support
----------

Basically what we have at the moment, but without version numbers in jar
names and symlinks.

 + simple, doesn't require lots of faff
 + no fake transitions
 - no coinstallability of old versions
 - all real transitions cause flag days

Separate -dev packages
----------------------

The heavy-weight approach that is most like C and relies on the package
manager a lot.

 + transitions don't need to be coordinated so much
 + can have coinstalled packages of different versions
 + build-depends don't change between versions
 + most transitions can be binnmus
 - lots of -dev packages which only contain 1 symlink

Combined -dev/-doc packages
---------------------------

As above, but the -dev also contains the javadoc

 + transitions don't need to be coordinated so much
 + can have coinstalled packages of different versions
 + build-depends don't change between versions
 + most transitions can be binnmus
 - -dev packages are potentially large and you build-depend on them

Post-inst symlink control
-------------------------

All the library packages contain postinst/prerm scripts which ennsure
the symlink always points to the most recent version, there is no
separate -dev.

 + transitions don't need to be coordinated so much
 + can have coinstalled packages of different versions
 - build-depends do change between versions
 - transitions can't be binnmus

Conflicting packages
--------------------

Library packages conflict with other versions of themselves and contain
the unversionned symlink.

 + transitions don't need to be coordinated so much
 - can't have coinstalled packages of different versions
 - build-depends do change between versions
 - transitions can't be binnmus

Matt
-- 
Matthew Johnson

Attachment: signature.asc
Description: Digital signature


Reply to: