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

Re: How to deal with teTeX's and texlive's RC licensing bugs



Norbert Preining <preining@logic.at> wrote:

> Hi Frank!
>
> Great work you have done, thanks a lot!
>
> On Don, 28 Sep 2006, Frank Küster wrote:
>> >> dviutils
>> > 	the texlive tpm bin-seetexk provides more binaries, namely
>> > 	in addition dvibook and dvitodvi, and I didn't want to loose
>> > 	them
>> 
>> It seems these have been added to bin-seetex.tpm by Karl, so we can't
>> just tell dviutils' maintainer to package a new version.  I think we
>> should declare Provides:/Conflics:/Replaces: (P/C/R) dvitutils in
>> texlive-extra-utils, so everything is fine for texlive users.
>
> Or I blacklist only those files which are in the Debian package and
> recommend it? What do you think?

Yes, this is probably better.  But only slightly; I don't know how much
hassle it is to blacklist individual files.

>> an ethiop-fonts package, too.  But as a short term solution I suggest
>> P/C/R. 
>
> For ethiop I leave if for now, too much work to sort this out ...

You mean, you just keep the Conflicts?  There are no files in ethiop
that are missing in texlive, except of course things like individual
debian/copyright.  So I think we can safely add Provides/Replaces.

>> and so on.  None of these are actual file conflicts, and since there's
>> no conflict with tetex-base, either, it means they are all in a
>> different place in the TEXMF tree (generic/ivritex instead of
>> generic/babel).  So the only purpose that the Conflicts might have is to
>> prevent ivritex's files shadowing texlive's.  But I don't think this
>> actually warrants a Conflicts; I'd rather document it in README.Debian
>> and arrange with ivritex's maintainer about who's going to provide what.
>> 
>> Or, as texlive people, contact ivritex upstream and ask them to upload
>> there releases to CTAN, so that they can be included in texlive.
>
> Both too much work ATM for me, sorry.

Okay, but if you tell me how to edit README.Debian for a particular
binary package, I'll add the remark and drop the conflict.

>> >> ptex-bin
>> > 	binary of the same name, ptex
>> 
>> Is the ptex package actually maintained?  I only remember getting
>> bugreports about it... Anyway, we should check whether we can't P/C/R
>> it. 
>
> Kohda-san, please, do you have any knowledge about this? I guess we can
> live with this conflict (texlive-lang-polish <-> ptex). If there is
> someone who writes with ptex AND in polish, that would be funny.

A polish scientist working on far-eastern language or culture?

>> > Furthermore, the problem is that all these packages depend only on
>> > tetex, so as long as the maintainers don't upload new packages I cannot
>> > change the dependency order.
>> 
>> Yes, that's a problem.  Solved with an axe with P/C/R, or by much more
>> work.  
>
> I am in general against this axe, as I had bad experiences with it.
> AFAIR there is the problem that there are no versioned
> replaces etc, but this is long lost from my too small brain. ANyway. I
> hope it is not necessary...

One can declare versioned Replaces, but it might well be that this
doesn't work together with Provides and Conflicts.

>> IMO opinion we should make it a release goal for etch+1 that nothing
>> depends or build-depends on tetex exclusively, so that we can
>> systematically check for build problems with texlive, and eventually
>> drop tetex in etch+2.
>
> depends I think is going quite well. Build depends is a desaster.

But it's easy to unintrusively NMU.  We just need to arrange with the
release team post-etch.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: