Problems with tlmgr
Stephen Montgomery-Smith
is bad. Then when I run the perl script it is meant to link to, it
cannot find various include files. Then when I modify the perl script
to include the appropriate directory, tlmgr fails because some database
hasn't been created. I realize now that texlive is not ready for
mainstream ports.
On the other hand, I installed texlive directly from the installer from
tug.org, and it all worked like a dream. I have a sense that
texlive-freebsd is trying to reproduce what install-tl is doing, but not
doing it correctly.
Do you think it might make sense to do a texlive port that is merely a
wrapper for install-tl? One of the things that ports bring that
install-tl doesn't have is pkg-plist. The port could run install-tl,
along with creating links from /usr/local/bin to /usr/local/texlive.
And then deinstalling the port would conveniently delete these links.
And it could include "@unexec rm -rf /usr/local/texlive" which is all
that is needed to get the file system back to its pristine state.
Creating a wrapper around somebody else's package manager is what I did
with the octave-forge ports. It just makes sense to me not to try to
reproduce what someone else did.
Stephen
Stephen Montgomery-Smith
> I installed texlive from ports. tlmgr is not working. First the link
> is bad. Then when I run the perl script it is meant to link to, it
> cannot find various include files. Then when I modify the perl script
> to include the appropriate directory, tlmgr fails because some database
> hasn't been created. I realize now that texlive is not ready for
> mainstream ports.
>
> On the other hand, I installed texlive directly from the installer from
> tug.org, and it all worked like a dream.
I take this back. xdvi produced the error
/libexec/ld-elf.so.1: Shared object "librpcsvc.so.4" not found, required
by "xdvi-xaw"
This means that the binaries do have to be built from scratch, and that
the installer at tug.org doesn't do this.
Romain Tartière
> I installed texlive from ports. tlmgr is not working. First the link
> is bad. Then when I run the perl script it is meant to link to, it
> cannot find various include files. Then when I modify the perl script
> to include the appropriate directory, tlmgr fails because some database
> hasn't been created. I realize now that texlive is not ready for
> mainstream ports.
AFAICR, tlmgr(1) is a GUI tool to install / upgrade packages from the
CTAN mirrors. The goal of the freebsd-texlive project (as I started it)
was to integrate TeXLive in the ports, which means having ports
depending on TeXLive parts. For this purpose, I think that packages
versioning is a must-have: without information about the installed
version of say hyperref, you may not know why some port that depends on
TeXLive does not build correctly on the system of an user.
But TeXLive packages are not versioned. The idea was therefore to
create ports for each package and use the last modification date as
version. This way, it is possible to manage TeXLive packages as any
other packages and update everything using only e.g. portmsater(8).
> On the other hand, I installed texlive directly from the installer from
> tug.org, and it all worked like a dream. I have a sense that
> texlive-freebsd is trying to reproduce what install-tl is doing, but not
> doing it correctly.
texlive-freebsd tries to integrate TeXLive in the ports. The ports
system already has it's metadata "databases" so adding another one looks
odd to me. And just like on can install apache by hand in some random
location, one can install TeXLive using install-tl / tlmgr without
benefiting from the ports system integration if he wishes.
> Do you think it might make sense to do a texlive port that is merely a
> wrapper for install-tl? One of the things that ports bring that
> install-tl doesn't have is pkg-plist. The port could run install-tl,
> along with creating links from /usr/local/bin to /usr/local/texlive.
> And then deinstalling the port would conveniently delete these links.
> And it could include "@unexec rm -rf /usr/local/texlive" which is all
> that is needed to get the file system back to its pristine state.
If you have a way to determine if a TeXLive package has been updated
upstream and you can perform the update with the ports system, this is
almost Okay to me.
> Creating a wrapper around somebody else's package manager is what I did
> with the octave-forge ports. It just makes sense to me not to try to
> reproduce what someone else did.
As far as I see, we have to workaround the lack of version information
in the TeXLive distfile filenames. Maybe we can do this differently.
At the moment, the update scripts mirrors the TeXLive repository,
extracts all packages metadata, and update ports according to it. This
is quite painful but I can't figure out another way to provide good
TeXLive integration in the ports system. I am open to suggestions for a
better system.
Romain
--
Romain Tartière <rom...@blogreen.org> http://romain.blogreen.org/
pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
Stephen Montgomery-Smith
> On Thu, Oct 13, 2011 at 09:02:48PM -0500, Stephen Montgomery-Smith wrote:
>> I installed texlive from ports. tlmgr is not working. First the link
>> is bad. Then when I run the perl script it is meant to link to, it
>> cannot find various include files. Then when I modify the perl script
>> to include the appropriate directory, tlmgr fails because some database
>> hasn't been created. I realize now that texlive is not ready for
>> mainstream ports.
>
> AFAICR, tlmgr(1) is a GUI tool to install / upgrade packages from the
> CTAN mirrors.
This was my real question. How do I change from A4 to letter page paper
with the texlive freebsd ports as you have them now. If I can fix this
one thing, the the texlive freebsd ports will be completely usable for me.
I don't think tlmgr is GUI. The command sequence recommended by all the
sites I found using google was "tlmgr paper letter."
I know that I am currently using A4, because when I print in the USA,
the margins are slightly off.
Romain Tartière
> I don't think tlmgr is GUI. The command sequence recommended by all the
> sites I found using google was "tlmgr paper letter."
I was not aware of this. I used to use this in all documents:
\documentclass[a4paper]{...}
Now, I use XeTeX and add this:
\usepackage{geometry}
\geometry{a4paper}
I can't tell you the difference (if any) between the 3 methods ...
Stephen Montgomery-Smith
> On Sat, Oct 15, 2011 at 11:05:49AM -0500, Stephen Montgomery-Smith wrote:
>> I don't think tlmgr is GUI. The command sequence recommended by all the
>> sites I found using google was "tlmgr paper letter."
>
> I was not aware of this. I used to use this in all documents:
> \documentclass[a4paper]{...}
>
> Now, I use XeTeX and add this:
> \usepackage{geometry}
> \geometry{a4paper}
>
> I can't tell you the difference (if any) between the 3 methods ...
I think the documentclass command is telling latex how to fill up the A4
paper. Whereas the "tlmgs paper letter" command is telling dvips and
xdvi to set the margins. I think they are different things.