This is the mail archive of the
mailing list for the Cygwin project.
Re: [RFC] 1.7 Packaging: Obsolete packages
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 24 Jul 2008 11:43:13 +0200
- Subject: Re: [RFC] 1.7 Packaging: Obsolete packages
- References: <email@example.com>
- Reply-to: cygwin-apps at cygwin dot com
On Jul 23 23:43, Yaakov (Cygwin Ports) wrote:
> What I *do* know about by now is porting and packaging for Cygwin,
> having done it for almost five years now. And with the transition to
> 1.7 coming up, there are a few general packaging issues that I think it
> would be timely to address.
Can't contribute much to your points but...
> The first thing is that I think a mass rebuild is in order. There are
> too many packages that are outdated, dependent on old libraries, or that
> would greatly benefit from the new features in 1.7 (or 1.5 for that
To reiterate, the most important features of Cygwin 1.7 to consider when
rebuilding packages, because of how they influence building applications
- IPv6 support, new functions getaddrinfo, getnameinfo.
- minires and libresolv.a are now part of Cygwin.
- PATH_MAX has changed from 260 to 4096. getcwd() can potentially
return paths of up to 32K.
- Potentially case sensitivity file operations (on OSes and FSes
- New file conversion API for conversion from Win32 to POSIX path and
vice versa (cygwin_conv_path, cygwin_create_path, cygwin_conv_path_list).
> 1) try to make 1.5->1.7 like 1.5.x->1.5.y.
> *If* it's possible, then this would theoretically make it easier for
> users to upgrade. When the necessary packages are rebuilt, then the old
> libraries could be removed from the distro, but the empty compatibility
> packages may need to remain.
> 2) start over with a new install.
> This may be more difficult for users, depending on how they use Cygwin,
> and depending on what will ultimately be necessary for handling a
> straight upgrade. As for the packaging, it would give us the chance to
> dump a lot of old baggage and make some additional changes without
> worrying about now-ancient history.
I'm not sure if there's really a big difference between these two points.
Since we're using two different installation directories, we can get rid
of old cruft, if we just look carefully what's still used and what not.
The release-2 directory has already no obsolete packages anymore. Stuff
like minires, which is now a part of Cygwin, can entirely go away as
soon as all packages relying on resolver functions have been rebuilt.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com