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

Bug#107264: tetex-src: duplicates files from tetex-extra



Hi Robert, hi Thomas

three years ago Robert reported the following bug to our Bugtracking
system. Sorry for not following up on this (I don't know what happened,
since I wasn't a member of the team back then).

Robert Bihlmeyer <robbe@orcus.priv.at> wrote:

> Subject: Re: tetex-src: duplicates files from tetex-extra
> Package: tetex-src
> Version: 1.0.1+20000804-2
> Severity: minor
>
> Example:
>         tetex-extra: /usr/share/texmf/bibtex/bst/natbib/plainnat.bst
>         tetex-src: /usr/share/texmf/source/latex/natbib/plainnat.bst
> these are the same. Other bsts in the same directories are duplicated
> as well.

This may be viewed as a bug or as a feature, depending on how one views
tetex-src (tetex-texmfsrc.tar.gz). If it's just there for copyright
reasons, i.e. because packages require that the source code be
available on the same "media" as the extracted TeX input files, then
it's a bug.

If, however, one sees the src collection as a tool for (La)TeX
developers, it may e regarded as a feature that they get the complete
source directories, and not only the files that are not directly used. 

Please also note, Robert, that if one installs tetex-src for developping
purposes, he/she will frequently generate or re-generate package
documentation with the implementation docs included. This will rather
soon take the same amount of space as the 4MB you say we can save by
removing those dupes. And if one is only interested in the source for a
single package, it's probably better to get it from CTAN.

> I went and did more checks, and there is some intra-package
> duplication as well:
>         /usr/share/texmf/source/latex/misc/curves.tex
>         /usr/share/texmf/source/latex/curves/curves.tex
> are exactly the same, but not soft- or hard-linked. 

The same here: if the files exists in both source directories, and are
needed in both, they should be there if it is viewed as a developer
tool. 

However, there is one inconsistency, it seems (Thomas?): vf, tfm and mf
directories for fonts are usually only in tetex-texmf, but for cmbright
(and for eulervm in the current beta), there are mf ant tfm (vf and tfm,
respectively) directories. Is there a specific reason for this - my
predecessors decided to delete those directories in the tetex-src
package. 


> There are numerous
> other examples. I listed them with the one-liner:
>
> perl -e 'for $p (@ARGV) { open L, "dpkg -L $p|" or die "dpkg -L $p: $!"; while (<L>) { chomp; -f $_ && -s _ or next; chomp($s = `md5sum <$_`); $n = join(":",(stat _)[0,1]); $b = -s _; if (exists $f{$s} && $f{$s}{n} ne $n) { print "$f{$s}{path} ($f{$s}{pkg}) vs $_ ($p) [$b]\n"; $sum += $b } else { $f{$s} = {pkg => $p, path => $_, n => $n} }}} print "$sum bytes could be saved\n"' tetex-extra tetex-src
>
> This gives more than 500 dupes with a total save potential in excess
> of 4 MB!
>
> It would be very nice if this duplication could be removed. One
> possibility would be to symlink one location to the other, if a dupe
> cannot be altogether removed.

I am not so fond of doing this in Debian, if upstream choses to keep the
duplication: It will require a lot of maintenance, especially when files
are moved to new locations with a new upstream release. We could
consider doing it if you, Robert, help us, by refining the Perl code. 

It would have to 

- search through a texmf tree - not the installed one, but rather once
  through the tree created for packaging tetex-base, and once for the
  respective tetex-extra tree, and compare the files with equal names

- check whether the files are really files or just symlinks. If they are
  symlinks, this is because we moved them to /var/lib/texmf or
  /etc/texmf - i.e. they will either be modified by scripts, or are
  modifyable by local admins, and we can't symlink to them.

- be easily maintainable (script instead of one-liner, descriptive
  variable names, etc.pp.

Thank you both,
Frank

-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie




Reply to: