Initially I thought we could do without their installer, because I found only 4 types of "execute", i.e. post install script actions in the master texlive.tlpdb on CTAN. Then I had a look at their new packager's sources: http://www.tug.org/svn/texlive/trunk/Master/tlpkg/TeXLive/. Besides the 4 generic "execute" types, there are plenty of hardcoded package-specific things in TLPostActions.pm. So, I don't see an easy way of dealing with this. Duplicating all that stuff in rpm post scriptlets would be highly unmaintanable. The only sane way would be to install their packager library first, and to execute post actions from there as needed, which needs at least a wrapper script since that code is Perl. It's more than I have time for this weekend... On Sat, Aug 9, 2008 at 11:35 AM, Vasile Gaburici <vgaburici@xxxxxxxxx> wrote: > That file Jonathan pointed me to is a converter from the old TeXLive > tpm format, which is now obsolete. The guy that wrote that script, > Norbert Preining, is one of the principal authors of the new TeXLive > packaging system. Too bad he doesn't dig Fedora. > > The TeXLive folks are pretty serious with this installer. They've got > an API, but the only complete bindings are in, cough, Perl. There's a > talk here that describes some of the API and more importantly the new > package structure; skip the incoherent part until Norbert starts > talking - you'll see a slide with his name when that happens around > minute 19: [http://www.river-valley.tv/conferences/bachotex2008/#0104-Reinhard_Kotucha]. > His sildes are here: > [http://www.logic.at/staff/preining/talks/bachotek08-talk.pdf]. I'm > summarizing the essential points from the talk below. > > A single package is described by a file ending in ".tlpobj", which is > generated starting from a ".tlpsrc", which is an auto-filled spec > basically because it can be as simple as the package name; the missing > info is pulled from CTAN. The ".tlpsrc" can use complex regexp patters > to describe the files, but AFAICT the ".tlpobj" is equivalent to a rpm > manifest in that it contains an exact file list, dependencies and a > post install script; you have license info too. The key slide (for us) > from the talk is the one describing the fields of a tlpobj: > [http://www.cs.umd.edu/~gaburici/tlpobj_fields.PNG]. It looks good > enough to make a rpm from it! As you can see TeXLive versions the > stuff from CTAN in their own svn. This is quite useful for us because > stuff from CTAN is often an unversioned pain. An example tlpobj: > [http://www.cs.umd.edu/~gaburici/tlpobj.PNG]. Another one that goes > with the quote "this is something new - we have dependencies": > [http://www.cs.umd.edu/~gaburici/tlpobj2.PNG]. They also have a > complete database by concatenating all the ".tlpobj" files in the file > "texlive.tlpdb". The API from 10,000 feet: > [http://www.cs.umd.edu/~gaburici/tlpobj_API.PNG]. A 5-page paper that > gives a bit more detail than my paragraph: > [http://www.logic.at/staff/preining/pubs/guit07.pdf]. I was unable to > find the API documentation on the net however; it's probably in their > svn somewhere. If you have any luck, let me know. > > Another bit of relevant info from the talk is that there are about > 1500 packages (more than Debian has!), but 1200 of them are simple > (LaTeX) style files. I his talk he mentions that (until April) he had > not done any work towards integrating the new TeXLive with any Linux > distro. He also predicts that we'd be in trouble since we can no > longer "hack around" ;) > > Also, going back to an earlier question of Patrice, Norbert mentions > that there's support for regenerating fmutil.cnf, language.dat, and > updmap.cfg from a database (whatever that means) plus local additions, > which is probably what Patrice wants. > > Hope this helps, > Vasile > > On Fri, Aug 8, 2008 at 1:33 AM, Jonathan Underwood > <jonathan.underwood@xxxxxxxxx> wrote: >> Not quite the same thing, but there is tpm2deb which is here: >> >> http://svn.debian.org/wsvn/debian-tex/texlive2008/trunk/tpm2deb-source.pl?op=file&rev=0&sc=0 >> >> ... might have a look to see how hard it would be to re-plumb that to >> produce rpms. >> >> J. >> >> > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list