Putting my packages up for adoption
Thu May 1 22:58:00 GMT 2008
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
> 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:
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.
More information about the Cygwin-apps