frakturx is a font package for LaTeX, containing a variety of fraktur / blackletter fonts. I've made an ebuild for it about two years ago, and it was sitting in the gentoo-de overlay since then, but this overlay will be shut down end of March. So I guess it's time to move the package to the main tree. Alexis, could you have a look at it, before I commit this? I'm not sure if the directory layout is sane. I'll attach the ebuild and the output of qlist. Also, what category is preferred? dev-tex or media-fonts?
Created attachment 178135 [details] frakturx-20070103.ebuild
Created attachment 178137 [details] output of "qlist frakturx"
(In reply to comment #0) > Alexis, could you have a look at it, before I commit this? I'm not sure if the > directory layout is sane. I'll attach the ebuild and the output of qlist. The layout seems sane; Just some nitpick: maybe add a symlink for the pdf/ps/dvi files in ${TEXMF}/doc/latex/${PN}/ so that e.g. 'texdoc WieynkFraktur' works nicely I know we have a lot of packages not doing this but that's something nice to have :) Also, why repackaging this into one single package ? wouldn't it be simpler to have 1 gentoo package <-> one fraktur font package; maybe that'll even simplify the ebuilds by letting latex-package.eclass do everything for you (even the texdoc stuff). > Also, what category is preferred? dev-tex or media-fonts? I'd say dev-tex as the fonts are really only for (la)tex as far as I can see; we already have such font packages there anyway.
Thank you. > Just some nitpick: maybe add a symlink for the pdf/ps/dvi files in > ${TEXMF}/doc/latex/${PN}/ so that e.g. 'texdoc WieynkFraktur' works nicely O.K., will do. > Also, why repackaging this into one single package ? wouldn't it be simpler > to have 1 gentoo package <-> one fraktur font package; That's probably a matter of taste. I can do that if you strongly dislike the current solution. That'd be one base package, eleven font packages, plus maybe a meta package that pulls all of them in. (And I guess when upstream changes the "base" package, then everything has to be redone.) An intermediate solution would be to keep the original distfiles (only rename them to be versioned). > maybe that'll even simplify the ebuilds by letting latex-package.eclass do > everything for you (even the texdoc stuff). I think the ebuild cannot profit from this, since the original ZIP archives have the same deep directory structure as the repackaged tarball. I forgot to ask, tex herd (and myself as maintainer) is O.K. with you?
(In reply to comment #4) > > Also, why repackaging this into one single package ? wouldn't it be simpler > > to have 1 gentoo package <-> one fraktur font package; > > That's probably a matter of taste. I can do that if you strongly dislike the > current solution. That'd be one base package, eleven font packages, plus maybe > a meta package that pulls all of them in. (And I guess when upstream changes > the "base" package, then everything has to be redone.) I have no strong opinion about this: that's more or less what texlive does anyway, big collections of packages; this is simpler to handle for ebuilds deps & co but this disallows single updates or forces to reinstall the whole thing for one single package (but that also that avoids to completely bloat the portage tree with thousands of ebuilds :) ). I usually try to do one ctan package <-> one ebuild for tex packages that we don't grab from texlive though. > An intermediate solution would be to keep the original distfiles (only rename > them to be versioned). imho that'll be simpler to maintain than having to repackage everything at each bump > > maybe that'll even simplify the ebuilds by letting latex-package.eclass do > > everything for you (even the texdoc stuff). > > I think the ebuild cannot profit from this, since the original ZIP archives > have the same deep directory structure as the repackaged tarball. ok > I forgot to ask, tex herd (and myself as maintainer) is O.K. with you? yes of course
Committed to tree, thanks again.
