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:27:49 -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>
- Reply-to: Cygwin Apps List <cygwin-apps at cygwin dot com>
Warren Young wrote:
> Yes, but the package name changed, so I think all I have to do is ensure
> the RFU request says to leave libexpat0 alone, right? Then other
> package maintainers can rebuild for libexpat1 at their leisure. Unless,
> that is, it's a big deal to port to expat 2?
There's more to it than that. When libfoo<n> transitions to libfoo<n+1>
there is a need to create an explicit source package for libfoo<n>,
because building from the 'foo' -src package of foo now creates
libfoo<n+1>. In other words, you need to make a copy of the old source
corresponding to the <n> abi and make it into its own -src package so
that it remains possible to rebuild libfoo<n> from sources on the
mirrors. This means that the setup.hint for libfoo<n> no longer simply
contains an 'external-source' line but has its own -src package.
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.
This is completely separate from the issue you mention that you need to
keep the binary compatibiliy package around until all packages in the
distro have been rebuilt against libfoo<n+1>, at which point you can
finally retire it (which means bumping the release number and uploading
a corresponding new package that contains an empty tar file, with
category changed to _obsolete.)
Brian