[pgf-tikz] CTAN Upload: pgf

[Henri Menke]

Dear CTAN,

On 02/03/21, 14:51, Petra Rübe-Pugliese wrote:
> On Tue 02 Mar 2021 at 14:16:53 +0100  Henri Menke <ctan at henrimenke.de> wrote:
> > On Tue, 2021-03-02 at 12:47 +0100, Petra Rübe-Pugliese wrote:
> 
>  [...]
> 
> > Nothing has changed in the PGF source tree with regards to the README since the
> > last release,
> 
>  It is sadly true that there is no README file in the present
>            ctan:/install//graphics/pgf/base/pgf.tds.zip
>  either  :-\
> 
> > which was accepted without such complaint.
>  
>  Well, we sometimes make and overlook errors, too.
>  In the case of pgf this is not astonishing due to over 450 lines
>  of output (!) when our checker checks "pgf" (compared to
>  virtually 0 lines for "normal" packages).
>  All this due to innumerable exceptions we made with respect
>  to multiple identical copies of files, files with identical
>  names, INSTALL_NOTES in one layout and not the other,
>  you name it.
>  In such a flood of Warnings a single Error line concerning
>  a missing README is _easily_ overlooked.

If it is too much of a mental challenge to just add an exception for
files ending in .lua, then I can't help you.  Alternatively, you ask the
Lua developers whether they want to switch to kpathsea for file lookup.
Good luck with that.

>  There are in our internal notes 61 lines of what has to be
>  specially considered when installing this package
>  (vs. 0 lines for "ordinary" packages).

Well, why is this list not public?  You can't reasonably expect me to
abide by any of your rules if I don't know them.  This lack of
transparency is annoying and this sentiment is shared by other TeX
developers.

>  But there is a limit to everything.
> 
>  It is one of our _basic_ rules, and _not_ one made up on the
>  spur of the moment, that the content of the "flat" tree
>  has to be _equivalent_ to the content of the .tds.zip
>  file (except for "generated" files that should _not_
>  be in the "flat" tree).

Okay, honestly I absolutely do not give a shit about this stupid flat
tree format.  It just leads to common installation errors, where users
and even TeX distributors [1] simply pull the flat tree and attempt to
pop it into the TDS tree, which of course horribly fails.  On top of
that the documentation (which I believe is this
https://ctan.org/help/upload-pkg but who knows what kind of hidden
documentation is floating around) is extremely vague and just leaves me
guessing as to what is going to be accepted or not.

By the way, before I submit a release to CTAN I *always* submit it to
the https://www.ctan.org/submit/validate endpoint first.  Why do I even
bother if this is apparently doing nothing?

I'm not going to resubmit the current release because Git is very rigid
and I don't want to fuck over my contributors by breaking their
checkouts of the repository.  Looks like users will have to wait for
3.1.10 until they get an update.

Cheers,
Henri

[1] https://github.com/MiKTeX/miktex-packaging/issues/80

>  In particular there has to be a README file in the .tds.zip
>  file, too.
>  
> > I would really
> > appreciate if the CTAN team would not make up new arbitrary rules with absolute
> > zero benefit for either the user or the developer with every new release I push.
> 
>  See above.
> 
>  And I cannot agree that a README file is of zero benefit for users.
> 
>  I will _not_ accept a .tds.zip file without a README in it,
>  and I will not repair your .tds.zip file for you.
>  Please correct your build script for the benefit of this
>  release and future ones.
> 
>    Best regards,
>        Petra
> 
> -- 
> Please send messages to ctan at ctan.org in English only.
> Please do not send HTML messages, they are held in our spam filter.
> Please do not send software via email, use the web upload form. Thanks!