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

Bug#411537: texlive-extra-utils: Installs /usr/bin/dvidvi, which is also in package dvidvi



On Tue, Feb 20, 2007 at 01:04:41PM +0100, Frank Küster wrote:
> Frank Küster <frank@debian.org> wrote:

>> $ findpkg -r dvidvi

> > usr/bin/dvidvi						    tex/dvidvi,tex/texlive-extra-utils

>> ,---- http://release.debian.org/etch_rc_policy.txt
>> | Packages must not install programs in the default PATH with
>> | different functionality with the same file name, even if they
>> | Conflict:.
>> `----

> That actually doesn't apply here, since the functionality is the
> same.  We could as well conflict in this case, but I guess it's
> better to exclude dvidvi from texlive, and Recommend: dvidvi
> instead.  Unless the dvidvi maintainer thinks otherwise, of course
> (Cc'ed).

That would be acceptable. Another solution would be to have the
texlive source package build dvidvi into a separate binary package,
and to request removal of the dvidvi source package. What I'm
actually trying to do here is to sneakily shift responsibility for
dvidvi from me into the Debian TeX maintainers' lap. But if you don't
want that, OK, fine, I can continue with the dvidvi package as I did
before.

Does the dvidvi from texlive contain the same patches (and hence
really the same functionality) than the one in the dvidvi package, or
maybe even better ones?

I took a cursory glance, it seems they both contain unique features:

 - the one in texlive bears version number 1.1, as opposed to 1.0, and
   accepts command line switches -j and -p.

 - the one in texlive seems not to contain the patches in dvidvi, in
   particular not the patch for the section of the manpage and not
   Benjamin Bayart's patches, or not all of them.

 - texlive seems to be missing a Unix version of a5booklet

How about merging them, pushing the changes in dvidvi to upstream
(that is texlive) and building a dvidvi binary package from texlive?

-- 
Lionel



Reply to: