Mailing-List:	contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender:	cygwin-apps-owner AT cygwin DOT com
List-Subscribe:	<mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-apps/>
List-Post:	<mailto:cygwin-apps AT cygwin DOT com>
List-Help:	<mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To:	mailing list cygwin-apps AT cygwin DOT com
Message-ID:	<103a01c18603$84a934b0$0200a8c0@lifelesswks>
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	"Charles Wilson" <cwilson AT ece DOT gatech DOT edu>, <cygwin-apps AT cygwin DOT com>
References:	<3C18EBA9 DOT 9030102 AT ece DOT gatech DOT edu> <20011213215926 DOT GA20163 AT redhat DOT com> <3C192A8F DOT 168CF40F AT ece DOT gatech DOT edu>
Subject:	Re: Restructuring gettext
Date:	Sun, 16 Dec 2001 18:30:20 +1100
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime:	16 Dec 2001 07:30:11.0715 (UTC) FILETIME=[7F051D30:01C18603]

----- Original Message -----
From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
> > The term "glutton for punishment" springs to mind.

:]


> > I think we should consider it the responsibility of the package
maintainer
> > to maintain all occurrences of the name of his package.  So, it
would
> > be within your right to change mutt to accomodate your changes -- as
> > long as you let the mutt maintainer know about this.
>
> Okay, I can do that currently -- but once the meta-data is folded into
> the -src archive (bin archive?) it gets a bit trickier.

I think it's unreasonable to hand the package maintainer responsibility
to look after anyone who depends on their package. I think it is
reasonable to expect the package maintainer to do what Chuck has done
and announce here the imminent arrival of destructive changes.

As for the meta-data (bin archive BTW) interacting with this, yes it
does get more complex.
The key things will be:
1) once a package-version-suffix hits the mirrors, it gets frozen. The
only changes allowed will be to external metadata - categories, and
stability. Dependencies and conflicts will not be able to be changed
without a new upload.
2) Once a package-version-suffix hits the mirrors, it can be depended on
by anyone, and so that version must not be removed until all dependent
packages have been updated. It can be superseded (and moved out of
current).
3) Per version dependencies are a MUSThave for 1 and 2 to make sense,
and thus for in package metadata.

> Any other comments about the restructuring itself?  Unfortunately, I
see
> this sort of thing being necessary for a lot of packages that provide
> DLL's: and not just because "we" change the way we build 'em.
Sometimes
> the upstream folks change the API -- like readline.  Hopefully these
> disruptions can be "spaced out" so they don't all hit at once...

If the API changes, bump the .dll number and the package number. One
thing I've seen debian (who face this issue much more often than RPM
based distro's due to the decentralised upload regime) do is have
libncurses0, libncurses1,libncurses2 etc, which is NOT related to the
version of ncurses, but to the major version number libtool generates
(and any package that changes the API without updating the libtool
compatability triplet (which may or may not bump the major version
number) should get shot at by rednecks).

> Anyway, I'm treating the "lib*" packages as "shared lib only" and the

Yes.

Rob

- Raw text -