This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Restructuring gettext


----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]