pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Checksum SHA1 mismatch for tex-helvetic-2009/helvetic.tar.xz

On Mon 27 Sep 2010 at 10:02:42 AM +0200, Adam Hoka wrote:
>On Sun, 26 Sep 2010 18:17:23 -0700
>George Georgalis <> wrote:
>> I've been getting checksum errors today for fonts/tex-helvetic
>> any idea why? pkgsrc-2010Q2
>Upstream doesnt give a damn about their users and changes files without 
>version or location. Please try ask them to change this behaviour, it may 

Perhaps its just a question of Start Of Authority. I think their
mission is to take care of their users by not confusing them with
version numbers... actually I have the feeling documentation
authors (their primary users) probably aren't interested in
version numbers at all. Unfortunately there is a breakdown when
coordinating with a 3rd party (pkgsrc in this case).

In any event, I think version numbers are important. I wrote their
archive hierarchy group the following email. But I'm not interested
in moderating a disagreement; perhaps the easiest solution is to
add timestamp versions to mirrored files, as I think someone else
suggested. Not sure what server or who's hands would be best for
that. I'm happy to offer up the resources if needed.

I'm writing about the absence of version numbers in the
tex archive files. I imagine this has been discussed before and
I'm not interested in reloading a flame. But from a 3rd party
perspective, there is a problem with not having versioned archive
files available. I appreciate the convenience of always having
the same name for release files but the specific consequence of
only releasing archives that way is the inability of third parties
to perform integrity validation. When one version is tested, and
another version is released of the same name, the validation
testing fails.

I propose, continuing to offer unversioned files in the tex archive
but also offering versioned equivalents for a limited time.

for example if helvetic.tar.xz was also available as

Than anyone requiring specific versions could access the
particular ones and symlinks or copy of the original would make
the unversioned name also available. A policy of 6 months hosting
of deprecated versions (if they don't have security issues) would
aid in coordination as well.

I appreciate tug is a *big* project and infrastructure with many
factors to consider. If retooling infrastructure, bandwidth or
disk-space is an issue, perhaps hosting the archives on sourceforge
or similar would solve that problem---create a branch repository
there for release versions and let them manage hosting, storage
and bandwidth?


Home | Main Index | Thread Index | Old Index