This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Putting my packages up for adoption
- From: Brian Dessent <brian at dessent dot net>
- To: Warren Young <warren at etr-usa dot com>
- Cc: Cygwin Apps List <cygwin-apps at cygwin dot com>
- Date: Thu, 01 May 2008 15:57:43 -0700
- Subject: Re: Putting my packages up for adoption
- References: <4817A587.8070803@ukf.net> <48186957.9050503@etr-usa.com> <4818F69A.3020405@ukf.net> <481A3F3D.4050309@etr-usa.com> <481A43E5.74027D93@dessent.net> <481A459B.30306@etr-usa.com>
- Reply-to: Cygwin Apps List <cygwin-apps at cygwin dot com>
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