I'm finding it hard to maintain the biber package. One reason is that it closely tracks the package texlive-biblatex and both change quickly upstream. I propose decoupling biblatex from texlive. Here is a new "tex-biblatex" package. This isn't really ready for a proper; just looking for feedback. I extracting some of this from texlive.spec and the rest from looking at asymptote.spec. For now I'm targetting biber 2.9 and biblatex 3.9 (minimal change from what we currently have in rawhide) but would eventually track current upstream releases. New package: Spec URL: https://cbm.fedorapeople.org/tex-biblatex.spec SRPM URL: https://cbm.fedorapeople.org/tex-biblatex-3.9-1.fc27.src.rpm
I do not have an issue with this (it's one less tex component I have to worry about), but given how tightly this is tied to biber, does it make sense to include it in the biber srpm and have texlive-biblatex generated as a subpackage? It is worth noting that I'm very very close to updating texlive for Fedora 28+, which will bring biblatex svn42680 (3.7), which is the newest that has been pushed to CTAN. It seems like biblatex isn't keeping up in CTAN, so that may not be helpful.
Thanks! I'll play with this idea a bit more when I have time and then ask for a proper review. CTAN seems to have 3.11 as of 2018-03-04? And if I understand correctly, it was 3.8a in Nov 2017. But I don't really understand the relationship b/w texlive and ctan so maybe this isn't relevant.
CTAN has 3.11, but the biblatex in TexLive is stuck at 3.7 (31-Dec-2017). See also: https://tug.org/svn/texlive/trunk/Master/texmf-dist/bibtex/bib/ Would you like me to update to 3.11 in rawhide & F28? It might make more sense just to add it as a subpackage to biber now, which I'm happy to help with.
They are not bundled upstream but I don't mind either way: whatever is easier to maintain. I would certainly like some help. There is a list TODO list in my spec file above. I was originally thinking 2.9/3.9 for F28 and 2.11/3.11 for Rawhide (just because it looks like various changes came in 2.10) But we can be bolder than that :-)
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
@spot the latest bump of texlive and biber was poor (b/c I wasn't paying attention to what was happening in texlive). So let's try to get this fixed up. I updated my draft spec: https://cbm.fedorapeople.org/tex-biblatex-3.12-1.fc31.src.rpm https://cbm.fedorapeople.org/tex-biblatex.spec Re: subpackage of biber: all things being equal I rather follow upstream. Is it so bad to `Requires: biber = 2.12` (and `Requires: tex-biblatex = 3.12` in biber)? Things I don't know how to do: (a) remove biblatex from texlive packages (b) deal with the `texlive-biblatex-*` packages. See my TODOs at the top of the spec file. Can you help? thanks, Colin
Maybe I foresee trouble with updates: cannot submit the two packages one-at-a-time to koji, need buildroot. Although maybe I have the deps wrong: biber definitely needs biblatex but maybe biblatex does not necessarily need biber.
Giving this more thought: There are a lot of biblatex dependent components in TeXLive. Separating it out and maintaining texlive-biblatex independently seems like a great way for people to have a poor experience if the rest of the biblatex dependent packages break. That said, this is not one of the areas of TL where I have any expertise. If you think this can be done, we can certainly try to disconnect texlive-biblatex from the rest of TL. If you're going to tie texlive-biblatex closely to biber, I think you may still want to keep them in the same src package, to minimize the risk of incompatibilities. That's up to you though. Let me know what you'd like to do, and I'll make the necessary changes in rawhide when you're ready.
Can we add a version-specific dependency on biber to texlive.spec? Something like this diff: %package biblatex Provides: tex-biblatex = %{tl_version} License: LPPL Summary: Bibliographies in LaTeX using BibTeX for sorting only Version: svn49069 Requires: texlive-base Requires: texlive-kpathsea-bin, tex-kpathsea +Requires: biber >= 2.12 Requires: tex(standard.bbx) Requires: tex(authoryear.bbx) Requires: tex(biblatex.sty) Requires: tex(etoolbox.sty) Requires: tex(keyval.sty) Requires: tex(logreq.sty) Requires: tex(ifthen.sty) Requires: tex(url.sty) Provided that version number was kept up to date (somehow!) then we'd have to bump biber to bump texlive... More work for you :( - - - - - I've forgotten how the other texlive binaries are dealt with... What would it take to get biber back into texlive.spec? Right now its explicitly killed by "tlpdb.patch".
> That said, this is not one of the areas of TL where I have any expertise. If you think this can be done, we can certainly try to disconnect texlive-biblatex from the rest of TL. Me either! I think you've convinced me its a bad idea to try to take it out... Maybe the simplest approach here is just to somehow ensure I get notified when you're going to bump texlive.... how can we do that? Can you add a "ping Colin via email" to your texlive workflow?
I've added the Requires: biber >= 2.12 to the texlive-biblatex subpackage. I also added a note to the top of the spec file to remind me to email you if I update biblatex. As far as adding biber back into texlive-base (where the other binaries live)... that one is odd. I don't think biber is part of the upstream texlive source code anymore. There is still a texlive component for it (with binaries and source), but the raw tl source tarball doesn't have any code (or reference to it). It clearly did at one point, because there is a --disable-biber in the texlive-base.spec (which came from the old giant texlive.spec), but the configure file ignores that option entirely.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.