On Sun Aug 02 20:39, Marcus Better wrote: > > Separate -dev packages > > ---------------------- > > > > The heavy-weight approach that is most like C and relies on the package > > manager a lot. > > > > + build-depends don't change between versions > > By this you mean we build-depend on a virtual package like libfoo-dev, which > is Provided by libfoo0-dev, libfoo1-dev and so on? > > This is not very good since it assumes the package will build correctly with > all future versions of the library. I prefer the more conservative policy of > build-depending on the actual dev package (also for C libraries). Well, there's two ways of doing this in C libraries. Some provide versionned -dev packages and some don't. In the case of the unversionned ones then if you try and rebuild after a transition you will link against the new version, which may fail. I'm not sure whether we should enforce/allow either or both method. If you do require versionned dev packages you again have the problem that a transition can't be handled with just a binnmu. > > Post-inst symlink control > > ------------------------- > > Definitely much nicer. > > > All the library packages contain postinst/prerm scripts which ennsure > > the symlink always points to the most recent version, there is no > > separate -dev. > > If by "version" you mean "API version" (as you said above), then this is a > bad idea. That would mean that packages would suddenly build against a > different API version than intended. See above, the same would apply > So these symlinks should encode the API version in their name (similarly to > C), and point to the most recent upstream version that provides this API. > > > - build-depends do change between versions > > Yes, between API versions, as I think they should. In which case, there's no reason to have the symlink, since the jar itself will have the API version (and not package version). This gives us another option then: Coinstallable packages but without symlinks ------------------------------------------- jars have api version in the name, there are no 'plain' symlinks and hence no -dev packages. + coinstallable old versions + transitions don't have to be coordinated + no -dev packages - transitions need build-dep / rules changes Matt -- Matthew Johnson
Attachment:
signature.asc
Description: Digital signature