Re: Orphaned packages looking for new maintainers

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

 



On Wed, May 19, 2021 at 2:39 PM Michael J Gruber <mjg@xxxxxxxxxxxxxxxxx> wrote:
> spec
> actually provides a "tex-preview" package that is just preview.sty and
> is used by several packages to do tex rendering and preview:
> $ repoquery --repo=rawhide{,-source} --whatrequires tex-preview
> Last metadata expiration check: 0:02:29 ago on Tue 18 May 2021 11:25:34 PM
> BST.
> R-tikzDevice-0:0.12.3.1-4.fc34.src
> R-tikzDevice-0:0.12.3.1-4.fc34.x86_64
> dot2tex-0:2.11.3-9.fc34.noarch
> emacs-auctex-0:12.1-9.fc33.noarch
> gnuplot-latex-0:5.2.8-7.fc34.noarch
> ktikz-0:0.13.1-2.fc34.x86_64
> latex2html-0:2020.2-3.fc34.noarch
> psi4-1:1.3.2-10.fc35.src
> python-matplotlib-0:3.4.2-1.fc35.src
> python-mplcairo-0:0.4-1.fc35.src
> python-networkx-0:2.5.1-2.fc35.src
> qtikz-0:0.13.1-2.fc34.x86_64
> sdcc-0:4.0.0-5.fc34.src
> texlive-collection-latexextra-9:svn54851-38.fc35.noarch
> texstudio-0:3.1.1-1.fc35.x86_64
>
> I have no need for the emacs portion of this package and only need the
> preview.sty portion for texstudio, so I really don't want to take it on as
> a full package. I can see three options for this:
> 1) Someone adopts the full package and maintains it (it was orphaned for
> FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=1923372)
> 2) It gets retired and I have to introduce a new package just for the tex
> file
> 3) The texlive-preview subpackage gets renabled in the main texlive
> distribution and provides this instead (since CPAN also contains this file
> and includes it inside upstream texlive technically, but we just don't
> package it there).
>
> My preference is either 1 or 3 happens, since I think it would be bad to
> have a standalone package maintained independently for just that tex file.
>
> Does anyone use the emacs plugin this provides (auctex) and would be
> willing to take on this package?
>
> -Ian

I'd say that packaging a texlive file in another package is wrong anyways, so I'd suggest 3) in any case, with the possibility that someone can still take up auctex, fix the emacs-lisp error and make auctex depend on texlive-preview (and, for good measure, fix the unversioned obsoletes for tetex-preview).

I agree, but from what I can tell emacs-auctex is actually the upstream for preview.sty and they feed into CPAN on their releases - so I think the texlive maintainers decided to use it as the upstream instead of texlive in this case. Hopefully Spot can weigh in on this as well as the primary maintainer of texlive.

-Ian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux