[tex-live] psutils maintenance

[Jay Berkenbilt]

Reuben Thomas <rrt at sc3d.org> wrote:

> On 24 October 2013 14:47, Jay Berkenbilt <qjb at debian.org> wrote:
>
>     I remember having expressed a few concerns in previous email.
>
> I've looked through all the emails I've had from you about psutils,
> and I found three points, all already addressed:
>
> 1. Compilation on Win32: obviously not a concern for Debian, but I've
> tried to address it already insofar as possible through gnulib.
>
> 2. Debian patches: I have already incorporated them.
>
> 3. Dropping the fix* scripts: I have dropped the fix* scripts as being
> not worth maintaining. If you want to continue to package them, that
> should be easy: just move them into the Debian patch. I've not seen
> any interest e.g. from TeXLive in continuing to use them. My
> inclination would be to drop them and wait until someone complains,
> then file a bug report upstream (to me!): I'd certainly be sympathetic
> to users who actually do still need the scripts.
>
> --
> http://rrt.sc3d.org

Hello again.  I've left this message marked "unread" in my debian inbox
since October in hopes of finding the time to deal with it.  I finally
looked at it today.

For debian, I have to take a hard line on backward compatibility.  Who
knows who out there has scripts or other stuff that relies on the
scripts that you chose not to include.  I don't really want to go
through the hassle of including the scripts and so forth in the form of
patches or to deal with the headache of multiple source tarballs when
one includes duplication of the other.

So, in order for me to want to include this in debian over the existing
version, I would need to see all the programs that were installed with
the old version.  This is not because I disagree with your conclusions
about them; it's just that experience convinces me that removing stuff
will backfire, and the cost of keeping it in is very low.

My suggestion to you would be to create a directory called something
like "old-scripts" in which you can place these items.  These are
basically the files that are in the existing debian psutils package but
not in the version you have.  Since these are all scripts, it should be
easy to just take them.  I know debian's psmerge and psjoin differ
significantly from upstream and are known to work better.  You could
take the debian versions if you want.

fixdlsrps
fixfmps
fixpsditps
fixpspps
fixscribeps
fixtpps
fixwfwps
fixwpps
fixwwps
getafm
includeres
psmerge
showchar
fixdlsrps.1
fixfmps.1
fixpsditps.1
fixpspps.1
fixscribeps.1
fixtpps.1
fixwfwps.1
fixwpps.1
fixwwps.1
getafm.1
psmerge.1
showchar.1

I think I'm okay with the debian package having to run ./bootstrap as
long as it doesn't try to grab anything from the network as this makes
the build impossible on a non-Internet-connected system.  If I add build
dependencies on automake and autoconf but not git and use ./bootstrap
--skip-git --skip-po, it fails.  I think it would be best if I could
just grab a source tarball in the traditional sense that already has all
the automatically generated files in it.  This would be easier for
people who directly download psutils as well.  I might be able to be
convinced that that's outdated thinking.

So, while I'm willing to switch to your more modern version with patches
included, I would only do so if doing so simplified packaging and
maintenance without removing any programs that people may be depending
on.

Thanks again, and sorry for taking so long to reply.

-- 
Jay Berkenbilt <qjb at debian.org>