Announcement

Collapse
No announcement yet.

Texlive2009 - why not use their own in-house installer which can do much more?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Texlive2009 - why not use their own in-house installer which can do much more?

    I've recently changed over to using Kubuntu, even though I have had a reasonable amount of prior experience with Linux systems, and ran an earlier version of Kubuntu for over a year continuously about 3 years ago. I've used KPackageKit to install TexLive and have tried the installation out with Kile. The problem is it is not as up to date as it could be: This can be easily solved by using TexLive2009's in-house perl scrips for installation and updating, and doing it this way will ensure that recent style files and the complete system can be installed. However, given that I used KPackageKit, I find that various packages and style files as well as font files have not been bundled in with Debian's sources which Kubuntu rely on, and there is no easy way of installing them by hand because it appears that KPackageKit installs the files in different locations to those used by TexLive2009.

    My questions are these: What are the relative advantages and disadvantages of bypassing KPackageKit to install TexLive2009 using its own installer and manager (install-tl and tlmgr, respectively)? Has anyone done it this way succesfully? What are the problems associated with having previously installed Kubuntu's version of TexLive2009? I presume I would have to go through and uninstall those components first, and wonder if anyone has ever done this? Would Kile still be easily able to find the appropriate programs, etc?

    Sorry for the number of questions: I have determined that the installation script (install-tl) runs up to the point at which it begins installing files, and that I have a working accessible unzip to hand, but I do not want to muck things up and cause me a lot of work fixing some broken installations if I can get some indication of the facts that are answers to the above questions. Many thanks.
    Qu Dawei: Stoke-on-Trent, UK (Note: The family names come first for Chinese names)

    #2
    Re: Texlive2009 - why not use their own in-house installer which can do much more?

    HOWTO: TexLive 2009 + Greek using Xetex
    Windows no longer obstructs my view.
    Using Kubuntu Linux since March 23, 2007.
    "It is a capital mistake to theorize before one has data." - Sherlock Holmes

    Comment


      #3
      Re: Texlive2009 - why not use their own in-house installer which can do much more?

      Originally posted by Snowhog
      Thanks for the reply, which tells me that it seems to work as far as the person concerned had tested it under Ubuntu.

      If I run the installation script "as is", the installation of TeXLive2009 proceeds and populates the TeXLive2009 standard directories (different to those chosen by KPackageKit or Synaptic or apt-get for installation of TeXLive2007). So, the end result is a mixed and possibly muddled (mis-matched) installation of two different versions of TeXLive that may cause problems until the environment variables are set as advised in the TeXLive2009 installation guide. Subsequently, it is also rather wasteful in terms of available diskspace.

      Given that there was also a TeXLive2008, it also shows that something is not happening to update the available versions of TeXLive in the repositories.

      A further problem then arises which may bring about more problems under Kubuntu running KDE and the supplied TeX/LaTeX Integrated editor Kile (it probably wouldn't have arisen in the case of the UBUNTU example, provided before, unless that person also ran a mixed GNOME/KDE windowing environment) Kile is built with dependencies built in which require TeXLive2007 to be installed, which merely adds to the problems: at the least, the wasted disk space must be tolerated if one wishes to run Kile, and then there is the problem of the TeXLive2007 file structure apparently hard-linked into Kile, meaning Kile is tied to the now out-of-date version of TeXLive2007. I know that this is a problem that should be primarily be directed at the Kile development team, but it does mean that if one wishes to upgrade to the next-but-one version of TeXLive (the current one), one then cannot use Kile. I am now having to use Texmaker as my IDE for TeX/LaTeX, for instance.

      The final problem is that if one wishes to use TeXLive2009, then one can no longer use KPackageKit, Synaptic, or apt-get to manage its installation, and this may further confuse ordinary end-users of TeX/LaTeX and put them off using any variety of Linux in favour of the seemingly more straightforward management procedures of MSWindows or MAC installations..

      So, thanks for the pointer, given above, but it didn't help all that much: in the end, I removed the now out-of-date installation of TeXLive2007, followed TeXLive's advice concerning directory structure and installed TeXLive2009, which has given me an up-to-date installation which provided tools for incremental updating of style files and TeX/LaTeX packages and fonts that remains a standard TeXLive installation. This has been at the cost of (a) being unable to use the otherwise excellent editing platform of Kile, (b) being unable to use any of KDE's supplied package managers to manage the installation, and (c) having what appears to now be a "non-standard" installation from the point of view of KDE.

      I think this is a bit messy, to be frank, and could well be off-putting to many users. The interested members of the KDE community would do well to try to address it.
      Qu Dawei: Stoke-on-Trent, UK (Note: The family names come first for Chinese names)

      Comment


        #4
        Re: Texlive2009 - why not use their own in-house installer which can do much more?

        The interested members of the KDE community would do well to try to address it.
        You're absolutely right. Unfortunately, "the interested members of the KDE community" do not, (with a few exceptions), frequent this site. They are busy doing other things. The way to reach them is via Launchpad or (less effectively) via Ubuntu Brainstorm.

        Slightly later: Unfortunately, contacting the Ubuntu developers will do you no good. Ubuntu (and variants, thereof) are built from Debian packages (with slight, mainly cosmetic modifications). The next version of Ubuntu (Lucid Lynx) will be generated from what is in Debian Testing in the very near future, i.e. if it isn't even in Debian Unstable, you won't see it in Ubuntu for at least a year. A check of the Debian packaging website indicates that texlive 2007 is still the only version in Debian.

        Comment


          #5
          Re: Texlive2009 - why not use their own in-house installer which can do much more?

          Originally posted by askrieger
          [...]
          Slightly later: Unfortunately, contacting the Ubuntu developers will do you no good. Ubuntu (and variants, thereof) are built from Debian packages (with slight, mainly cosmetic modifications). The next version of Ubuntu (Lucid Lynx) will be generated from what is in Debian Testing in the very near future, i.e. if it isn't even in Debian Unstable, you won't see it in Ubuntu for at least a year. A check of the Debian packaging website indicates that texlive 2007 is still the only version in Debian.
          Many thanks for the response. I think it seems clear what to now do: since I complained about this, I feel there is a case to be made that it should be me who takes the next step. Given what you have written, therefore, I will be identifying appropriate places in which to raise my points so that people concerned with the Debian packages can read them and respond if necessary, and I'll also do something similar in the case of Kile and their developers.

          So, once again, thanks.
          Qu Dawei: Stoke-on-Trent, UK (Note: The family names come first for Chinese names)

          Comment


            #6
            Re: Texlive2009 - why not use their own in-house installer which can do much more?

            Prior to retirement, I sometimes used an editing system called "Lyx" which is a front end to "Latex" (I'm not going to waste time reproducing Les Lamport's typesetting for the name of his program). Lyx is in the repos, but I notice that there are a couple of Texlive components listed as dependencies, so that may not solve your problem. Personally, I almost always just wrote straight Latex (see above) documents using Emacs. I was able to use the AAS and APS macro packages "revtex" and "aastex" to get printable documents, but (by that time), I wasn't trying to get them published. All of which may be irrelevent to your requirements.

            Comment


              #7
              Re: Texlive2009 - why not use their own in-house installer which can do much more?

              I've got TL09 running here. Everything works fine. However, installing it using the scripts that come with it messes up the "normal" system update process.
              This problem was addressed and solved here:
              http://kubuntuforums.net/forums/inde...9049#msg199049

              Comment


                #8
                Re: Texlive2009 - why not use their own in-house installer which can do much more?

                Originally posted by THHHB
                I've got TL09 running here. Everything works fine. However, installing it using the scripts that come with it messes up the "normal" system update process.
                This problem was addressed and solved here:
                http://kubuntuforums.net/forums/inde...9049#msg199049
                Thanks for the warning. It doesn't seem to have caused any problems to me so far, unless I am misunderstanding what you mean by "normal system update process".
                Qu Dawei: Stoke-on-Trent, UK (Note: The family names come first for Chinese names)

                Comment


                  #9
                  Re: Texlive2009 - why not use their own in-house installer which can do much more?

                  Originally posted by askrieger
                  Prior to retirement, I sometimes used an editing system called "Lyx" which is a front end to "Latex" (I'm not going to waste time reproducing Les Lamport's typesetting for the name of his program). Lyx is in the repos, but I notice that there are a couple of Texlive components listed as dependencies, so that may not solve your problem. Personally, I almost always just wrote straight Latex (see above) documents using Emacs. I was able to use the AAS and APS macro packages "revtex" and "aastex" to get printable documents, but (by that time), I wasn't trying to get them published. All of which may be irrelevent to your requirements.
                  When I first starting using LaTeX, it was on an old MSDOS-based machine, and so I got quite used to the sequence of software runs I had to do. I've also retired now, but after a break recovering my health (the cause of my early retirement), I'm returning to research I can do at home, and that is how I've re-established my use of LaTeX. I guess I have got "soft" over the years, but it would be quite easy for me to go back to a similar tactic, perhaps by using kate as part of the process. I commented on kile in my messages above as that was what I was using at that time, and it seemed to me that I would not be the only one with this kind of problem with out-of-date packages seemingly being hardwired into other software when they need not be.

                  Incidentally, I have discovered that the Texmacs supplied by apt-get/Synaptic/KPackageKit (Texmacs is another platform that integrates various TeX/LaTeX procedures) also has the old TexLive packages hard-wired into its installation. Luckily, I chose Texmaker, which doesn't, and which demonstrates that it isn't always necessary for these dependencies to be hard-wired in at installation. There is a distinction that may need to be made: (a) software that, for some reason, has hard-wired links to out-of-date TexLive dependencies only present for its *installation*, but not its running; and (b) software that has the out-of-date TexLive dependencies hardwired into the runtime software itself, meaning that it can neither be installed nor subsequently run without the out-of-date TexLive installation being present (in this case, to call upon).
                  Qu Dawei: Stoke-on-Trent, UK (Note: The family names come first for Chinese names)

                  Comment


                    #10
                    Re: Texlive2009 - why not use their own in-house installer which can do much more?

                    Originally posted by qu.dawei
                    Originally posted by THHHB
                    I've got TL09 running here. Everything works fine. However, installing it using the scripts that come with it messes up the "normal" system update process.
                    This problem was addressed and solved here:
                    http://kubuntuforums.net/forums/inde...9049#msg199049
                    Thanks for the warning. It doesn't seem to have caused any problems to me so far, unless I am misunderstanding what you mean by "normal system update process".
                    The "normal" Ubuntu package management uses a script that gets sorta displaced by a similar one installed by tl09. This is not really a problem, not until your system has to use this script... For me this was the case when I got an update for wget.

                    If you want to provoke this problem, do an reinstall (remove and install) of wget or mjpegtools. apt-get will call the "wrong" script (the one installed by tl09) and fail installing. Help is in the link I provided before

                    Comment


                      #11
                      Re: Texlive2009 - why not use their own in-house installer which can do much more?

                      Originally posted by THHHB
                      The "normal" Ubuntu package management uses a script that gets sorta displaced by a similar one installed by tl09. This is not really a problem, not until your system has to use this script... For me this was the case when I got an update for wget.

                      If you want to provoke this problem, do an reinstall (remove and install) of wget or mjpegtools. apt-get will call the "wrong" script (the one installed by tl09) and fail installing. Help is in the link I provided before
                      Very strange. I see what you and others have experienced, but I'm not getting it myself. The link you provided talked about TeXLive2008, and I am using TeXLive2009, but since you are, that isn't the difference. When I look for install-info in the place the links give, it isn't there.

                      However, I can find two kinds of install-info in other places: one in /usr/bin and the other in /usr/sbin. I let TeXLive2009 set up its own directory structure and it installed all its files in that (in /usr/local/texlive and subdirectories of it). I can't find any install-info in that branch at all.

                      If I try just running both versions of install-info (to see what happens without allowing them to do anything) I get the following messages:

                      Running /usr/local/bin/install-info gives this message:
                      This is not dpkg install-info anymore, but GNU install-info
                      See the man page for ginstall-info for command line arguments
                      install-info: No input file specified; try --help for more information.

                      Running /usr/sbin/install-info gives this message:
                      install-info: warning: don't call programs like install-info with an absolute path,
                      install-info: warning: /usr/sbin/install-info provided by dpkg is deprecated and will go away soon;
                      install-info: warning: its replacement lives in /usr/bin/.
                      This is not dpkg install-info anymore, but GNU install-info
                      See the man page for ginstall-info for command line arguments
                      install-info: No input file specified; try --help for more information.

                      and a "which install-info" tells me that on my system, the version found in /usr/sbin (the deprecated one provided by dpkg) is the one that would be run.

                      To uninstall wget to reinstall it would mean removing whole swathes of other programs, and so I tried to uninstall mjpegtools to see if it fails to reinstall. I didn't have it installed, and so I guess that merely installing it would be trhe same kind of test. It installed perfectly adequately with no problems.

                      Temporarily renaming /usr/sbin/install-info to /usr/sbin/install-info-dpkg meant that the install-info in /usr/bin would be run if required (I checked on this). So, I did this, uninstalled mjpegtools and then reinstalled it. It reinstalled with no problems again!

                      I used KPackageKit to do all the installing and uninstalling.

                      As far as I can tell, given our different systems and suchlike, I think my experience is different from yours and other peoples, and I'm not sure what has brought about the difference. I'll keep /usr/sbin/install-info as /usr/sbin/install-info-dpkg for now to see if any problems arise later, but can you see how I may have had no problems compared with yourself and others here?

                      Qu Dawei: Stoke-on-Trent, UK (Note: The family names come first for Chinese names)

                      Comment


                        #12
                        Re: Texlive2009 - why not use their own in-house installer which can do much more?

                        I just happened to reinstall my laptop yesterday (hdd died ;( ), and can confirm your observation. While TL08 causes this problem with install-info, TL09 does not and has its version installed in a different place, just like you said.
                        This is great! TL09 can be installed behind the Kubuntu package manager's back without causing problems Would be even better if Kubuntu shipped with the newest version of TL, but then again it would have to officially support this setup with the two package management systems installed. That would be a first afaik.

                        Comment

                        Working...
                        X