[RFC] 1.7 Packaging: Obsolete packages

["Yaakov (Cygwin Ports)" <yselkowitz at users dot sourceforge dot net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

As we start preparing for 1.7, I know that until now the focus has been
on the development of Cygwin itself.  I'll admit that I know little
about Cygwin's internals, and hence have contributed very little to the
DLL itself, but I do very much appreciate the work of those that do.

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.

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 matter).

Over the years a lot of cruft has accumulated within the distro, namely:

a) old versions of libraries (e.g. libintl{1,2,3});
b) empty _obsolete packages to smoothly handle renamings and such;
c) packages which are of little use and unmaintained.

At the same time, there could be some major transitions coming up:

d) some consistency in library package naming;
e) monolithic X11R6 in /usr/X11R6, to modular X11R7 in /usr.

More details on these later.

One of the key factors on how to handle all this, which I mentioned
briefly before, is that we need to make a decision on how we will expect
the user base to upgrade to 1.7.  The options are:

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.

There are obviously pros and cons to both; we need to make a decision
that will best serve the project and its users in the long term.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkiICHkACgkQpiWmPGlmQSPFsACgt283Vny05vFrNkb4H0VnyYPo
/JwAn0/xVpvt5quRTTQA5uciucImoKNh
=SZTY
-----END PGP SIGNATURE-----