Re: Putting my packages up for adoption
Yaakov (Cygwin Ports) wrote: For those that may be interested in adoption, there are updated versions of some of these now in Ports: Okay, thanks for the leg up. I'm guessing you'll keep maintaining these packages? I started my versions from yours, but had to remove several features because your archive has packages the official Cygwin distribution doesn't, and I don't want to maintain those, too. So, it would seem there's still a need for your versions.
Re: Putting my packages up for adoption
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 libfoon transitions to libfoon+1 there is a need to create an explicit source package for libfoon, because building from the 'foo' -src package of foo now creates libfoon+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 libfoon from sources on the mirrors. This means that the setup.hint for libfoon 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 libfoon+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
Re: Putting my packages up for adoption
Brian Dessent 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 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?
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 libfoon that can be used to build a libfoon 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
Re: Putting my packages up for adoption
Warren Young wrote:
Brian Dessent 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?
You can if you want to, but I never do. I just do this:
cp foo-1.2.3-1-src.tar.bz2 libfooN-1.2.3-1-src.tar.bz2
and edit libfooN's setup.hint to remove the external-source specifier.
I can see also building the devel package,
This is harder than you think, unless the upstream folks have already
done the heavy lifting. In most cases, however, the unaltered upstream
source for version N+1 installs its headers into the same place, with
the same names, as the upstream headers for version N.
Ditto the import libs (one exception is libpng, where you /can/ say
-lpng10 or -lpng12 because the implibs (and static libs) have different
names between the two versions. But /usually/ that is not the case, and
you have libfoo.a (and libfoo.dll.a) for both version N+1's and version
N. Since they both install into ${prefix}/lib, ...
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?
It's up to you, really. And sometimes, it's just not easy to do, because
of the above. Other developers who don't want to upgrade can keep their
existing setup, and use it -- or compile their own version locally into
a different prefix.
--
Chuck
Re: Putting my packages up for adoption
Warren Young wrote: Then other package maintainers can rebuild for libexpat1 at their leisure. Unless, that is, it's a big deal to port to expat 2? I believe it's merely a matter of rebuilding. Max. signature.asc Description: OpenPGP digital signature
Re: Putting my packages up for adoption
On Apr 29 22:34, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Max Bowsher on 4/29/2008 4:47 PM: | Accordingly I'm putting my packages up for adoption: | | * patchutils I use this enough to warrant adopting it. I'll post an ITA soon (although since it hasn't changed upstream, I'm not sure what the ITA would do other than repackage with cygport)... | Farewell, of sorts, and thanks everyone for helping make Windows a nice | place to be the past many years! Farewell, and thanks for your efforts. Sad ACK. I've marked all your packages as orphaned now. Keep rocking, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Putting my packages up for adoption
On Wed, April 30, 2008 3:27 am, Corinna Vinschen wrote: According to Max Bowsher on 4/29/2008 4:47 PM: | Farewell, of sorts, and thanks everyone for helping make Windows a nice | place to be the past many years! Sad ACK. I've marked all your packages as orphaned now. Would not a farewell gold star be appropriate?
Re: Putting my packages up for adoption
On Apr 30 04:20, Yitzchak Scott-Thoennes wrote: On Wed, April 30, 2008 3:27 am, Corinna Vinschen wrote: According to Max Bowsher on 4/29/2008 4:47 PM: | Farewell, of sorts, and thanks everyone for helping make Windows a nice | place to be the past many years! Sad ACK. I've marked all your packages as orphaned now. Would not a farewell gold star be appropriate? Sure! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Putting my packages up for adoption
Max Bowsher wrote: * doxygen I'm interested, contingent on seeing what it takes to build it. * expat I can do this one, but I'm concerned because expat.sf.net isn't responding right now. Did expat die again while I wasn't looking? * sqlite3 I know very little about using SQLite directly, so I may not be the right person to take it. I've been using it indirectly recently, so I have test DBs I can play with. I'll take a look at it in case no one better is found. Please email me the package build scripts, and brief instructions on their use. I maintain the ctags package, but do so with hand-rolled tools due to weirdnesses of its build system. So, I know how to build Cygwin packages, but I don't know how to build _your_ packages. :)
Re: Putting my packages up for adoption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 For those that may be interested in adoption, there are updated versions of some of these now in Ports: | * apr1 aprutil1 http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/libs/apr1/ http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/libs/aprutil1/ | * expat http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/libs/expat/ | * neon http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/libs/neon/ | * sqlite3 http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/db/sqlite3/ | * swig http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/devel/swig/ Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgYbf4ACgkQpiWmPGlmQSNrmACeM5tlA2iLWY/5H9sOPW1uwDm7 w/4An2dJH2GW3xdQT+dSUFy9ZlubRpcd =hoKQ -END PGP SIGNATURE-
Re: Putting my packages up for adoption
On Wed, 30 Apr 2008, Warren Young wrote: Please email me the package build scripts, and brief instructions on their use. I maintain the ctags package, but do so with hand-rolled tools due to weirdnesses of its build system. So, I know how to build Cygwin packages, but I don't know how to build _your_ packages. :) Warren, Downloading the corresponding source packages from the Cygwin mirrors should give you the exact set of tools used to build the packages. Depending on the packaging method, it could be as simple as running a script. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
Re: Putting my packages up for adoption
Max Bowsher writes: * neon Will take this one, it's needed by cadaver. Ciao Volker
Re: Putting my packages up for adoption
Warren Young wrote: Max Bowsher wrote: * doxygen I'm interested, contingent on seeing what it takes to build it. It's a most bizarre and quirky buildsystem that I've never seen any other package use. * expat I can do this one, but I'm concerned because expat.sf.net isn't responding right now. Did expat die again while I wasn't looking? I guess that's just SourceForge sucking. Worthy of note here is that you've got an ABI transition to deal with going from 1.95.x to 2.x, i.e. libexpat0 to libexpat1. (Assuming I remember rightly from when I dabbled with this). * sqlite3 I know very little about using SQLite directly, so I may not be the right person to take it. I've been using it indirectly recently, so I have test DBs I can play with. I'll take a look at it in case no one better is found. Please email me the package build scripts, and brief instructions on their use. I maintain the ctags package, but do so with hand-rolled tools due to weirdnesses of its build system. So, I know how to build Cygwin packages, but I don't know how to build _your_ packages. :) All my packages are generic-build-script based. I *think* that the base g-b-s version for each should be as follows: apache2, apr1, aprutil1, subversion: CVS r1.47 others: CVS r1.38 Max. signature.asc Description: OpenPGP digital signature
Re: Putting my packages up for adoption
On 4/30/2008 3:45 PM, Max Bowsher wrote: Warren Young wrote: All my packages are generic-build-script based. I *think* that the base g-b-s version for each should be as follows: apache2, apr1, aprutil1, subversion: CVS r1.47 I have a .cygport for subversion-1.4.6 if anyone's interested. I'm working on one for subversion-1.5.0-rc4. I may be interested in maintaining subversion since I use it daily. However, I only use the CLI under Cygwin, so I'm not very confident in my ability to test and troubleshoot the other components (apache mods, svnserve, perl, ruby, and python bindings, etc.) -- David Rothenberger [EMAIL PROTECTED] Dirksen's Three Laws of Politics: (1) Get elected. (2) Get re-elected. (3) Don't get mad, get even. -- Sen. Everett Dirksen
Putting my packages up for adoption
Greetings all, I've been using Linux exclusively at work for over a year. Today I've started dual-booting my primary machine to Linux too. I'm no longer going to be using Windows on a daily basis, so I don't think I'll be able to do an adequate job of package maintenance in the future. Accordingly I'm putting my packages up for adoption: * apache2 * apr1 aprutil1 * doxygen * expat * neon * patchutils * sqlite3 * subversion * swig I'll be keeping an eye on the list, if people want to ask any questions about the packages, and until adopters can be found I may still manage an update or two. Farewell, of sorts, and thanks everyone for helping make Windows a nice place to be the past many years! Max. signature.asc Description: OpenPGP digital signature
Re: Putting my packages up for adoption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Max Bowsher on 4/29/2008 4:47 PM: | Accordingly I'm putting my packages up for adoption: | | * patchutils I use this enough to warrant adopting it. I'll post an ITA soon (although since it hasn't changed upstream, I'm not sure what the ITA would do other than repackage with cygport)... | Farewell, of sorts, and thanks everyone for helping make Windows a nice | place to be the past many years! Farewell, and thanks for your efforts. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgX9tgACgkQ84KuGfSFAYDKxQCfXoUVIooEdM8hDCmLqI48H0T+ xE8AoMDmvee0IXRKE4/wnX6yOXR3uste =MO0N -END PGP SIGNATURE-
