cygwin-pkg-maint maintance

[Yaakov Selkowitz]

On 2014-08-10 15:33, Marco Atzeri wrote:
> I was looking at the needed maintenance of cygwin-pkg-maint,
> crossing the data of x86 setup.ini with cygwin-pkg-maint
> and I found 2 main classes of mismatch plus a minor one

Thanks for taking the time to look into this!

> 1) missing packages.
> Package that are in x86 setup.ini but not reported in cygwin-pkg-maint
> at any level.
> Nor the package, nor the source package and neither the first
> subdirectory of x86/release is reported in the file;
> I estimated the maintainer from the mailing list to be:
>
> PACKAGE                 SOURCE_PKG              MAINTAINER
>
> cloog-isl               cloog-isl               Achim Gratz
> db4.5                   db4.5                   Dr. Volker Zell
> db4.8                   db4.8                   Dr. Volker Zell
> db4.8-doc               db4.8                   Dr. Volker Zell
> font-misc-ethiopic      font-misc-ethiopic      Jon Turney
> glib1.2                 glib1.2                 Yaakov Selkowitz
> gtk1.2                  gtk1.2                  OBSOLETE (Yaakov Selkowitz)
> gtk1.2-engines          gtk1.2-engines          OBSOLETE (Yaakov Selkowitz)

The new upload mechanism doesn't seem to handle OBSOLETE well, so these 
two should be in my name without qualification in case I need to update 
them in the future.

> html2ps                 html2ps                 Yaakov Selkowitz
> isl                     isl                     Achim Gratz
> libart_lgpl_2           libart_lgpl_2           Yaakov Selkowitz
> libaudio-devel          nas                     Yaakov Selkowitz
> libaudio2               nas                     Yaakov Selkowitz
> libcloog-isl-devel      cloog-isl               Achim Gratz
> libcloog-isl-doc        cloog-isl               Achim Gratz
> libcloog-isl4           cloog-isl               Achim Gratz
> libedit                 libedit                 Corinna Vinschen
> libedit-devel           libedit                 Corinna Vinschen
> libedit0                libedit                 Corinna Vinschen
> libisl-devel            isl                     Achim Gratz
> libisl-doc              isl                     Achim Gratz
> libisl10                isl                     Achim Gratz
> libzzip-devel           zziplib                 Yaakov Selkowitz
> libzzip0.13             zziplib                 Yaakov Selkowitz
> mesa-demos              mesa-demos              Yaakov Selkowitz
> nas                     nas                     Yaakov Selkowitz
> nc                      nc                      Corinna Vinschen
> printproto              printproto              OBSOLETE (Yaakov Selkowitz)
> pwget                   pwget                   Jari Aalto
> xhtml2ps                html2ps                 Yaakov Selkowitz
> xlsx2csv                xlsx2csv                Jari Aalto
> zziplib                 zziplib                 Yaakov Selkowitz

The source packages should definitely be added; the subpackages depends 
on your last question.

> 2) packages that are in cygwin-pkg-maint but not in setup.ini (nor x86
> or x86_64 ones)
>
> most are OBSOLETE but not clearly defined as such, like
> db2, db3.1, .. of Volker
> libqhull, liblapack of mine

Do you have a complete list?

> 3) typos
>      libgck1-ddoc -> libgck1-doc
>      libzziplib-devel -> libzzip-devel

Yes, these are obvious fixes.

> Question before I start to modify cygwin-pkg-maint:
>
> Does still make sense to report all binary packages in
> the cygwin-pkg-maint files ?
> Should we cluster them at source package or directory level as accepted
> by the upload procedure ?
> Specially for the dll libraries the name are continuously bumped, and
> we will be always behind. At first glance we are missing ~ 200
> packages; so roughly 8% of all the binary packages (~ 2700).
> The active source packages are ~ 1400 and they change much
> less frequently (ITP, ITA, orphanage and obsolescence)
> so a better accuracy is possible.

I've actually been thinking along the same lines.  AFAICS, the new 
upload mechanism doesn't care about subpackage listings so long as the 
source package is listed (provided, of course, that the standard 
directory layout is used).

Therefore, the only "benefit" to having subpackages listed would be 
purely informative, but as you point out, 1) right now it's behind, 2) 
it's high maintenance for little gain, plus 3) a single person must 
anyway maintain an entire package with all its subpackages, and 4) nor 
does it actually indicate which subpackages map to which source packages.

So I am all in favour of making this a source-only list, in line with 
other distro package maintainer "databases".

Marco, if you're interested, please go ahead and add the missing 
*source* packages and fix those typos, but please hold off on removing 
anything until we hear from Corinna.

Thanks,

Yaakov