Steve Langasek <[EMAIL PROTECTED]> wrote: > The guidelines I believe we should be using when deciding such a bug is RC > as follows:
Thank you for your answer. > Have I overlooked any other outstanding issues in these bugs, or missed > important details about any of the files? Not in the bugs, but since this all got very confusing, I stopped forwarding to the bug all problems I found. They are all collected in the Wiki at http://wiki.debian.org/ProblematicCtanPackages The ones not discussed so far are: ,---- | euler: LPPL according changelog, but no indication in file. | | adrconv: No license at all for the documentation | | antp: PD according to catalogue, no statement in the files, no | sources; contacted upstream | | citesort.sty: no license statement | | index.doc: no license statement - probably unused | | dinbrief: lppl 1.1+, but with additional restrictions which are non-free | | a4wide.sty: no license statement, obsolete, uses a4.sty, should be removed | | bar.sty: no license statement except "don't modify", latex2.09, authors | are no longer at their listed affiliation => should be removed `---- Plus some under the heading "less serious problems". > For the issues that remain listed as "RC" here, I think the prudent course > of action is to remove them immediately from the orig.tar.gz so that we can > cross these RC bugs off. If you do get feedback permitting one or more of > these files to be distributed under a DFSG-compliant license, I'm ok with > allowing those files to be re-added during the freeze. Thank you. > Once the files in question have been removed, are these things that can be > checked with rebuild tests? The main problem to worry about is packages > which need a style that's been removed and fail to build, correct? Yes, that's the main concern, and it should be testable by rebuild tests. The other problem is with packages that have an ordinary Depends, here tests cannot be automated. However, if the package is actually used by some people, but problems aren't detected immediately because the removed files are used rarely and a problem shows up only in certain circumstances, then I think the package can stay in main and only has a normal or important bug, correct? Bugs in mostly unused packages are likely to slip through, anyway... > If so, we can ask for help from debian-qa for a targetted rebuild test. > This makes it even more important to get these files removed sooner rather > than later, to give us enough time for those rebuilds. Okay. Will try to do it during the weekend. > On Wed, Sep 27, 2006 at 07:20:44PM +0200, Frank Küster wrote: > >> What about option c: > >> - Remove all problematic files at once from tetex-base's orig.tar.gz, > >> - but keep them installed with texlive until somewhen at (release - n >> weeks), n=2,3 > >> - state that bugs that affect texlive's ability to be used as a teTeX >> replacement may be NMU'ed. > > I don't understand, what's the advantage here? If the bugs are present in > both texlive and tetex, surely we want to treat them the same for the > release, which means we should try to treat them the same now as well. There would have been an advantage only if you had not said "If you do get feedback permitting one or more of these files to be distributed under a DFSG-compliant license, I'm ok with allowing those files to be re-added during the freeze.", because even without re-adding them to etch, they would be available to etch users if they choose texlive (or install texlive packages in parallel with tetex, as far as that is possible). With that statement from the Release Managers, there's no advantage left. >> These bugs are in most cases just Depends: lines that only mention teTeX >> and do not allow texlive as an alternative. Among the packages any >> texlive package conflicts with, there might be some more. Some other >> conflicts just indicate that the package is not up-to-date, and texlive >> installs the newer version contained by upstream. Norbert? > > Sorry, I don't follow at all how this has to do with licensing bugs. Well, in the hypothetical case that you wouldn't let removed, now-free files be re-added during the freeze, it wouldn't help our users if we tell them "they are still available in texlive" if at the same time they cannot use texlive because other packages they need just don't permit it. And as I understand, "Please change Depends: tetex-extra to Depends: tetex-bin | texlive-base-bin, tetex-extra | texlive-latex-recommended " is just a wishlist bug and doesn't ordinary justify an NMU. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
