This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Putting my packages up for adoption


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]