Hi,
I would like to build lilypond for EPEL-7, but unfortunately it requires texlive-metapost which we don't have in the RHEL-7 texlive. Now, the question is how to build just one subpackage (or any required other subpackages) from the monstrosity which the current texlive? Anybody any suggestions?
Best,
Matěj
"MC" == Matěj Cepl mcepl@cepl.eu writes:
MC> Now, the question is how to build just one subpackage (or any MC> required other subpackages) from the monstrosity which the current MC> texlive? Anybody any suggestions?
Just package it separately. They should all have proper upstream tarballs, and there's no reason not to just make individual packages if that's what you need. And, hey, while you're at it, stick them in rawhide and make the texlive package not generate them at all. Anything that gets split out of texlive into proper packages is a win.
- J<
On 2015-04-08, 01:06 GMT, Jason L Tibbitts III wrote:
Just package it separately. They should all have proper upstream tarballs, and there's no reason not to just make individual packages if that's what you need. And, hey, while you're at it, stick them in rawhide and make the texlive package not generate them at all. Anything that gets split out of texlive into proper packages is a win.
Cutting up texlive monster piece by piece seems like rather lousy idea to me. After all that long thread about texlive which just happened here I am afraid dealing with the monster must be done in some more sensible and organized matter.
Anyway, I'll try to make a special EPEL package for it.
Matěj
On Wed, Apr 8, 2015 at 12:30 AM, Matěj Cepl mcepl@cepl.eu wrote:
On 2015-04-08, 01:06 GMT, Jason L Tibbitts III wrote:
Just package it separately. They should all have proper upstream tarballs, and there's no reason not to just make individual packages if that's what you need. And, hey, while you're at it, stick them in rawhide and make the texlive package not generate them at all. Anything that gets split out of texlive into proper packages is a win.
Cutting up texlive monster piece by piece seems like rather lousy idea to me. After all that long thread about texlive which just happened here I am afraid dealing with the monster must be done in some more sensible and organized matter.
Anyway, I'll try to make a special EPEL package for it.
Matěj
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
Don't anthropomorphize computers. They don't like it.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
One reason I'm building my OSJourno Docker images on Fedora and not the more popular and theoretically more stable CentOS is that EPEL doesn't have a few LaTeX packages I need. Sometime when I run out of more pressing things to fix, I'm going to try texlive-texliveonfly to see if it can find and install missing LaTeX packages.
Seriously, texlive is huge - if you install *everything* IIRC you have something like 4 GB just for texlive! So there's every reason to want to install a minimal texlive and install packages on an as-needed basis. And I'm curious why there are texlive packages in Fedora that aren't in EPEL - I assume it's a human or machine resource constraint.
On 2015-04-08, 08:12 GMT, M. Edward (Ed) Borasky wrote:
And I'm curious why there are texlive packages in Fedora that aren't in EPEL - I assume it's a human or machine resource constraint.
Not in EPEL, but in the RHEL-7. Obviously Red Hat delivers only a subset of whole TeXLive.
Best,
Matěj
On 04/08/2015 02:12 AM, M. Edward (Ed) Borasky wrote:
One reason I'm building my OSJourno Docker images on Fedora and not the more popular and theoretically more stable CentOS is that EPEL doesn't have a few LaTeX packages I need. Sometime when I run out of more pressing things to fix, I'm going to try texlive-texliveonfly to see if it can find and install missing LaTeX packages.
Seriously, texlive is huge - if you install *everything* IIRC you have something like 4 GB just for texlive! So there's every reason to want to install a minimal texlive and install packages on an as-needed basis. And I'm curious why there are texlive packages in Fedora that aren't in EPEL - I assume it's a human or machine resource constraint.
It's not that they aren't in EPEL, per se. It's that they aren't in RHEL7, as texlive is in RHEL7, and it is not as complete as the one in Fedora, for whatever reason.
Bug have be filed and hopefully some things will be added in RHEL7.2 (specifically metapost):
https://bugzilla.redhat.com/show_bug.cgi?id=1064453 https://bugzilla.redhat.com/show_bug.cgi?id=1198299
I'm sure that there are others, like:
https://bugzilla.redhat.com/show_bug.cgi?id=1200172
"MC" == Matěj Cepl mcepl@cepl.eu writes:
MC> Cutting up texlive monster piece by piece seems like rather lousy MC> idea to me.
I honestly don't see why. Surely fixing some of it is better than fixing none of it. And fixing some of it shows us how to fix the rest of it.
- J<
Once upon a time, Jason L Tibbitts III tibbs@math.uh.edu said:
"MC" == Matěj Cepl mcepl@cepl.eu writes:
MC> Cutting up texlive monster piece by piece seems like rather lousy MC> idea to me.
I honestly don't see why. Surely fixing some of it is better than fixing none of it. And fixing some of it shows us how to fix the rest of it.
Each time a small piece is sliced out of the giant package, the giant package must also be rebuilt to exclude that piece. That's a lot of churn on a giant package with a massive number of subpackages; it would be better to batch up pulling out lots of pieces at once.
On 8 April 2015 at 12:04, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"MC" == Matěj Cepl mcepl@cepl.eu writes:
MC> Cutting up texlive monster piece by piece seems like rather lousy MC> idea to me.
I honestly don't see why. Surely fixing some of it is better than fixing none of it. And fixing some of it shows us how to fix the rest of it.
I think the problem is that no one has figured out how to 'fix' a part of it. The best anyone has come up with was a machine generated 16MB spec file. We all keep looking at it, scratching our heads and then saying "Someone should fix that." knowing we can't.
On 8 April 2015 at 19:40, Stephen John Smoogen smooge@gmail.com wrote:
On 8 April 2015 at 12:04, Jason L Tibbitts III tibbs@math.uh.edu wrote:
> "MC" == Matěj Cepl mcepl@cepl.eu writes:
MC> Cutting up texlive monster piece by piece seems like rather lousy MC> idea to me.
I honestly don't see why. Surely fixing some of it is better than fixing none of it. And fixing some of it shows us how to fix the rest of it.
I think the problem is that no one has figured out how to 'fix' a part of it. The best anyone has come up with was a machine generated 16MB spec file. We all keep looking at it, scratching our heads and then saying "Someone should fix that." knowing we can't.
I look at tl2pm and think "it would be fairly easy to patch that to spit out 4000 and something spec files rather than one 16 MB one". The unresolved issues are whether doing that would invalidate the previous license audit (it shouldn't really), and whether FESCO would grant a package review exception for those packages.
On 04/08/2015 12:46 PM, Jonathan Underwood wrote:
I look at tl2pm and think "it would be fairly easy to patch that to spit out 4000 and something spec files rather than one 16 MB one". The unresolved issues are whether doing that would invalidate the previous license audit (it shouldn't really), and whether FESCO would grant a package review exception for those packages.
This may be worth pursuing. Or rewriting it in python :)
While we're at it I think we need to revisit the version numbers. Currently we have things like:
%global tl_version 2014 %global tl_rel 11 %global tl_release %{tl_rel}.%{source_date}%{?dist} %global tl_noarch_release %{tl_rel}%{?dist}
%package aastex Provides: tex-aastex = %{tl_version} Version: svn15878.5.2 Release: %{tl_noarch_release}.1
Provides: tex(aastex.cls) = %{tl_version} Provides: tex(aastex.sty) = %{tl_version}
This doesn't appear to comply with https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages which I believe would imply:
Version: 5.2 Release: #.svn15878
The Provides version seems fairly arbitrary, but perhaps there is a reason for it.
I've just spent the better part of two days packaging up a couple missing EL7 texlive packages for internal use, would be nice to get this fixed at the distro level.
Also, it is completely maddening that upstream does not appear to provide anything but the most current tarball for packages, e.g.:
Source0100: ftp://ftp.ctex.org/mirrors/CTAN/systems/texlive/tlnet/archive/aastex.tar.xz
unless anyone is aware of anything else? Perhaps we should be building from source: https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/source/latex/aastex/ or ctan?
On 04/08/2015 03:06 AM, Jason L Tibbitts III wrote:
"MC" == Matěj Cepl mcepl@cepl.eu writes:
MC> Now, the question is how to build just one subpackage (or any MC> required other subpackages) from the monstrosity which the current MC> texlive? Anybody any suggestions?
Just package it separately. They should all have proper upstream tarballs, and there's no reason not to just make individual packages if that's what you need. And, hey, while you're at it, stick them in rawhide and make the texlive package not generate them at all. Anything that gets split out of texlive into proper packages is a win.
+1 That's similar to the way we had split perl into pieces years ago.
Ralf