[tex-live] Should .tds.zip be encouraged? (was: characters > 127 in .dtx and .sty files)

[Robin Fairbairns]

Karl Berry <karl at freefriends.org> wrote:

>     Then perhaps such a "quick explanation" could be clarified where more
>     in-depth knowledge is needed. 
> 
> It is not so simple, and would not solve anything in the real world.
> Sorry.  In general, my experience is that if a package author is not
> interested in (or capable of) reading the full TDS document
> (tug.org/tds) and understanding it, and also looking at existing
> packages in TL and/or miktex to see what they do when they have
> questions, then they shouldn't be creating .tds.zip.
> 
>     For simple packages it ought to be enough, though.
> 
> Preparing the first tds.zip for a simple package is not so hard.  But
> that is only one step.  You also have to keep the .tds.zip updated (many
> times that does not happen), and ensure its consistency with the non-tds
> sources (many times that does not happen), avoid screwing up in creating
> the zip file (many times that happens), etc., etc.

these have been common enough in the past, i agree.  i don't believe
they occur often, nowadays; we check every .tds.zip before installing
it, and every .tds.zip on the archive is tested every night, so that
out-of-date (hence, presumably, with different content) ought to be
caught.

what we're not (yet) good at is checking that the derived content has
been updated properly.  there's also a problem with heiko's continuous
development model throwing up false positives if the .tds.zip is tested
before it or the main body has been updated.

> Meanwhile, for simple packages the standard ctan2tl conversion works
> fine and needs no work (ditto miktex, I'm sure).  And furthermore, it is
> additional work for the author to prepare, as you know.
> 
> So all this additional work is being done by everyone (the author, CTAN,
> TL, MikTeX), with nontrivial possibility of error at every stage, and
> the only benefit is to the people Robin mentions, that are "stuck" with
> their system installs and who are incapable of running the dtx file
> themselves ... but still want updates.  Not even close to worth it IMHO.
> 
> Complex packages, such as hyperref, vntex, and so on, conceivably do
> benefit from creating a .tds.zip.  I have no opinion on that.  Their
> (very experienced) authors know better than me what they should do.
> It's only promoting .tds.zip as an ideal approach in an ideal world to
> every neophyte author that I take issue with -- the world is not ideal.
> 
>     Which submission format is the least troublesome then? 
> 
> For my purposes: just upload to update the main CTAN tree.  No "format"
> is necessary.  A flat directory is fine.  Subdirectories are fine if you
> think it helps CTAN browsers (I flatten them :).

we actually ask for this (at most one level of subdirectory), in the
upload instructions.  we've given up trying to enforce this, since we
don't have the effort to continue arguing with users who know better
than us (or believe they do).

multilevel structures tend to leave the simple user confused.  one might
assert that such people oughtn't to be investigating what they're about
to get.  i, for one, tend to shout at users who've downloaded and
install stuff without investigating it, and then get themselves into
trouble; i'm not about to encourage authors to make it more difficult
for users.

>     Perhaps there should be a clearer message for package authors
> 
> I long ago updated http://tug.org/texlive/pkgcontrib.html (though few
> people see it), which is all that I control myself for TL purposes.
> 
> CTAN and I have discussed this issue ad infinitum (and they've discussed
> it without me plus infinitum), and of course what they do is up to them.

more than enough.  yet i keep putting my head above the parapet whenever
the issue gets discussed.  i'm going to get shot some time; the
department will be pleased -- the archive is a noticeable proportion of
the department's traffic (only a few tbytes/month, but it all adds up),
and bits transferred cost money.

r