Warren Young wrote: > > Otherwise, you potentially violate the GPL licensing requirement to > > provide the source as it would disappear from the mirrors entirely as > > new 'foo' versions pushed the old one off. > > So what I need to do, then, is rebuild the 1.95.8 package so it _only_ > builds the DLL package?
I think it's up to you how much you want to edit the package. The important thing is that you have a source package for libfoo<n> that can be used to build a libfoo<n> binary package. If that src package also generates foo and foo-devel binary packages (i.e. obsolete ones for the old ABI that would never be uploaded) then I don't think anybody would complain. But they'd never be used, as the whole point of the compatibility package is that it's just for things that haven't been rebuilt yet. > I can see also building the devel package, but > only if there's a lot of unwillingness to port to expat 2, and to know > whether that's going to happen, we have to release without and see what > happens, right? Well that's a whole other issue. The normal library versioning scheme only versions the binary runtime DLL package, and does not allow for anything but a single version of the -devel (and main) package. If you want to support the ability to have more than one -devel package it's *much* more work because you have to rename all the packages, and you have to make sure the headers for each -devel package get placed into their own versioned directory. For example, a normal library: foo: /usr/share/doc/foo-X.Y/readme.html foo-devel: /usr/include/fooheader.h libfoo0: /usr/bin/cygfoo-0.dll libfoo1: /usr/bin/cygfoo-1.dll versus: fooX.Y: /usr/share/doc/foo-X.Y/readme.html fooX.Z: /usr/share/doc/foo-X.Z/readme.html fooX.Y-devel: /usr/include/foo-X.Y/fooheader.h fooX.Z-devel: /usr/include/foo-X.Z/fooheader.h libfooX.Y: /usr/bin/cygfoo-0.dll libfooX.Z: /usr/bin/cygfoo-1.dll And then all clients that use libfoo have to "#include <foo-X.Y/fooheader.h>" or "CPPFLAGS=-I/usr/include/foo-X.Y" or some other scheme to select the desired version. Unless the library was designed to have this kind of versioned interface from the start it's not a very workable situation without modifying all downstream clients, which is why it's rather rare and the normal layout doesn't support it. For one example see the 'db' packages. Brian
