Re: TeXLive distribution and macports

[pagani laurent via macports-users]

> Well, if you want to use TeX to control your smart home*** (like
> lights and central heating system) and run a web server, the Knuth's
> version from 1978 is not going to cut it ...
> And if you want a fancy new feature that gets implemented a few hours
> after you request it  updating is the only way to get it.

we are far from writing a book or a paper ! Not sure Knuth foresaw that 
development! 

L.

"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise Shadok)

Re: TeXLive distribution and macports

[Mojca Miklavec]

On Tue, 11 Sep 2018 at 22:43, pagani laurent wrote:
>
> I have no idea why one needs to update Tex distribution several times a day 
> or even every week.

Well, if you want to use TeX to control your smart home*** (like
lights and central heating system) and run a web server, the Knuth's
version from 1978 is not going to cut it ...
And if you want a fancy new feature that gets implemented a few hours
after you request it  updating is the only way to get it.

Mojca

*** No, that's not a joke. ConTeXt can do that as well.

Re: TeXLive distribution and macports

[pagani laurent via macports-users]

Mojca,

Thanks for the detailed explanations.

> 
> I would say that a lot more reasonable would to switch to ConTeXt and
> then you don't really need much beyond perhaps 100 or 200 MB :)

hum, good to know indeed. There are so many variants, one never know which one 
to pick.Why MacPorts is not using ConTeXt rather than TexLive then ? Manpower, 
I guess...

> No, 3,5 GB is not entirely reasonable either; a factor of two doesn't
> really change the fact that TeX Live is to a great extent an
> uncensored monster.

agreed. I was living with the 2011 version (on /usr/local) which was ”only” 1.5 
Gb, it seems to be growing fast.

> He clearly explained that the version provided by MacPorts is way too
> outdated for his needs (it's only updated once per year).
> For a while in the past I also kept updating (another) TeX
> distribution several times per day, so I can totally relate to the
> situation.
> Think of an imaginary distribution like OpenDarwin that would only
> update package definitions from MacPorts once per year, and even then
> with about a month of delay.

I have no idea why one needs to update Tex distribution several times a day or 
even every week. AFAIAC, I have been working with the 2011 version until this 
morning without any trouble. I ”simply” write papers with Latex. Anyway, since 
I found that without installing TexLive in MacPorts it was indeed installed and 
occupying 1.5 Gb, I thought it was better to stick to that more recent one and 
remove the old 2011 version. But it was not a clever move because explicitly 
installing it doubled its size, so in the end I save no room. :-(
I guess I should explore the ConTeXt option and follow the recipe to tell 
MacPort to use that one.

>> (I did not find a version provided by Apple on my 10.12.6)
> 
> Apple does not provide any TeX distribution.

It was mentioned in one of the mails though, am I wrong ?

>> However I have one question :
>> 
>> I have a pair of .sty files which I would like my Latex editer (TexStudio) 
>> to automatically find. The simplest way is to add a /local/myfiles.sty in 
>> /opt/local/share/texmf-texlive/tex/latex as I used to do with my former 
>> texlive in /usr/local but I am afraid this might be erased each time I 
>> upgrade MacPorts. Am I wrong ?
> 
> It depends on how you update MacPorts. Just running "sudo port upgrade
> outdated" will not overwrite those files, but when you migrate to a
> new OS version, you might at some point manually run "rm -rf
> /opt/local" which will have that effect, yes.

Fair enough. Migrating to a new OS is always a mess, so a little more or a 
little less, no big deal.

> However, TeX is meant to support this scenario in a much better way.
> You should generally use one of these two:
>kpsexpand '$TEXMFLOCAL'
>kpsexpand '$TEXMFHOME'
> The second one usually resolves to ~/Library/texmf and I would
> probably use that one if I was you (of course you need a subfolder
> tex/latex/ if you have some latex styles) unless you want to install
> the files for other users as well (in that case you would go for
> TEXMFLOCAL).

Thanks. I did not know that. I will try that.

> 
>> Is there a way to protect this subdirectory (chmod to r+a would be ignored ?)
> 
> If you ever run "sudo rm -rf /opt/local", such "protection" won't
> help.

of course.

> Uninstalling packages will only remove files which belong to a
> particular package, so generally your files should not be deleted. But
> /opt/local/share/texmf-texlive is the wrong folder to use anyway.

Thanks for the advice.

Laurent

"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise Shadok)

Re: TeXLive distribution and macports

[pagani laurent via macports-users]

Hello,

> 
> More than 6GByte meanwhile…

If you ask for the full install, I guess. +medium is about 3.5 Gb, more 
reasonable.
> 

I chose the other way round : why not simply use texlive delivered by MacPorts 
and erase other versions ? (I did not find a version provided by Apple on my 
10.12.6)

However I have one question :

I have a pair of .sty files which I would like my Latex editer (TexStudio) to 
automatically find. The simplest way is to add a /local/myfiles.sty in 
/opt/local/share/texmf-texlive/tex/latex as I used to do with my former texlive 
in /usr/local but I am afraid this might be erased each time I upgrade 
MacPorts. Am I wrong ? Is there a way to protect this subdirectory (chmod to 
r+a would be ignored ?)

Thanks
Laurent


"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise Shadok)

Re: TeXLive distribution and macports

[Werner LEMBERG]

Hello Mojca!


> Warmly welcome to another addictive distraction (aka. MacPorts :),

So true...

> it's nice to see you here as well.

Thanks – it's time to meet again sometimes in the nearer future :-)

>> Ports that are ok with using MacTeX instead will have declared
>> their dependencies in such a way (using the bin: specification
>> instead of the port: specification) that MacTeX versions will
>> satisfy them.
>>
>> If you have MacPorts set up in this way, and you install a port,
>> and it still pulls in MacPorts texlive ports, then either those
>> ports' dependencies need to be fixed to use bin: instead of port:,
>> or there is a specific reason why those ports can't do it that way.
> 
> I wanted to reply something similar (but wouldn't be able to express
> myself as nicely as Ryan did).

Yeah, this sounds very promising!

> TeX Live is a bit special in the sense that it's a 5 GB(?) monster

More than 6GByte meanwhile...

> with only a bunch of command-line utilities (as opposed to providing
> libraries to link against, which would be prohibitive to make this
> kind of an exception) and advanced users would usually want their
> own special setup, or perhaps super up-to-date packages.

Exactly.  This year it is probably even more important than usual to
have access to an up-to-date repository since the LaTeX team decided
to make UTF-8 encoding the default in LaTeX, which causes quite a
number of packages to fail, and these failures are only detected now.

Additionally, packages for xetex and luatex are in most cases under
constant development.

> Before going into further detail I would like to point out that in
> the beginning I kind of tried to fight the same battle as you do now
> and tried to avoid installing TeX Live from MacPorts at all
> costs.

Hehe :-)

> We sometimes get requests for supporting installation of tlmgr only.
> This is something that's a lot more tricky in my eyes than just
> letting the user install TL himself and allowing some ports to
> forgive the dependency on texlive when that package is not
> present. (Code to prove us wrong is of course always welcome :)

I fully agree.

> 1.) Some ports like "dblatex" introduce a "+mactex" variant [...]

Yes.

> 2.) As Ryan already mentioned, one can specify a dependency in
> "bin:" form specification, so that either a local
> TeX installation or a port installed by the texlive port will
> satisfy the dependency.  If the specified binary doesn't exist,
> MacPorts will install the specified port. If it does exist, it
> won't install anything in additional.  See ftgl as an example of
> such a port.

Yes.  Looks very promising.

> The disadvantage is that it's nearly impossible to guarantee that
> the build will be successful in the case of a local TeX
> installation.

I can live with that, since it is an external dependency.  IMHO, it's
the job of the package's `configure' script to test that.

> [...]  For all those reasons I never bothered enabling external TL
> dependencies for asymptote and I'm still not sure if it is worth it.

Fortunately, the packages I'm interested in don't pose such problems.

> So in short: it definitely is possible to avoid installing any
> texlive-related packages from MacPorts.  The question is whether you
> care enough about this functionality to be willing to go into some
> extra troubles, and in any case there are probably a lot of ports
> that might need a patch to work as desired.

Yeah, will try to work on that.


Werner

Re: TeXLive distribution and macports

[Ryan Schmidt]

On Sep 9, 2018, at 10:23, Christopher Jones wrote:

> Note that MacPorts has a policy of not using external libraries, as far as 
> possible (apart from obvious system ones) so if you aim is to have a port 
> that basically allows something externally externally to pretend to be 
> something MacPorts provides, then no this is strictly not allowed. See for 
> instance
> 
> https://trac.macports.org/wiki/FAQ#ownlibs
> 
> its the same deal as why we do not support using anything installed outside 
> of MacPorts, from /usr/local

TeXLive is an exception to this rule. Users who wish to use the MacTeX TeXLive 
distribution instead of the one in MacPorts should edit 
/opt/local/etc/macports/macports.conf and add /Library/TeX/texbin to binpath.

Ports that are ok with using MacTeX instead will have declared their 
dependencies in such a way (using the bin: specification instead of the port: 
specification) that MacTeX versions will satisfy them.

If you have MacPorts set up in this way, and you install a port, and it still 
pulls in MacPorts texlive ports, then either those ports' dependencies need to 
be fixed to use bin: instead of port:, or there is a specific reason why those 
ports can't do it that way.

Re: TeXLive distribution and macports

[Mark Anderson]

Yeah, this is specifically prohibited by our guidelines and the overall
workings of the program. There is a TeXlive minimum install, and if you
could make one smaller that works with lily pond I’m sure we’d consider it.
But this is basically a non-starter with MacPorts.

—Mark

On Sun, Sep 9, 2018 at 12:31 PM Werner LEMBERG  wrote:

>
> >> Ah, I assumed too much knowledge, sorry.  TeXLive itself comes with
> >> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and
> >> recent versions, i.e., 10.10-10.13).  By simply prepending the path
> >> to those binaries to PATH, the `texlive-*' ports from MacPorts
> >> would be completely hidden and thus useless, more or less: TeXLive
> >> wouldn't use any data, binaries, or libraries from MacPorts.
> >>
> >> However, to build various packages like `lilypond', `port' needs to
> >> believe that some `texlive-*' ports are installed.  What certainly
> >> works is to create a small port repository similar to René Bertin's
> >> `macstrop' repository to override MacPorts with dummy ports.  My
> >> question was whether macports itself provides a simpler solution
> >> similar to `texlive-dummy-opensuse', where I have to install just a
> >> single .rpm file...  I guess the answer is no.
> >
> > Its quite simple.  The macports build of lilypond should be
> > configured to use the MacPorts provided builds of TexLive.
>
> I was still unclear, sorry.  To continue with lilypond as an example:
> This program uses only TeXLive *programs* and data, but no libraries.
> In general, this is true for all other programs within MacPorts that
> depend on texlive ports.  It is thus irrelevant whether MacPorts
> itself contains the necessary data and binaries, or whether they are
> provided externally (in this case, by the native TeXLive
> distribution).
>
> > If these ports do not provide what is needed, then just provide an
> > additional port for what is missing.
>
> There are no misses.  My `problem' is that the `texlive-*' ports
> within MacPorts use a few GByte, doubling everything native TeXLive
> already provides!  I want to use native TeXLive directly so that I can
> actually call `tlmgr' (or the SVN repository) to update the TeX stuff.
> For this reason I want to have some dummy portfiles to make `port'
> believe that the `texlive-*' ports are present.  This will take a few
> kBytes only...
>
>
> Werner
>
-- 
Sent from Gmail Mobile on iPhone

Re: TeXLive distribution and macports

[Werner LEMBERG]

>> Ah, I assumed too much knowledge, sorry.  TeXLive itself comes with
>> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and
>> recent versions, i.e., 10.10-10.13).  By simply prepending the path
>> to those binaries to PATH, the `texlive-*' ports from MacPorts
>> would be completely hidden and thus useless, more or less: TeXLive
>> wouldn't use any data, binaries, or libraries from MacPorts.
>> 
>> However, to build various packages like `lilypond', `port' needs to
>> believe that some `texlive-*' ports are installed.  What certainly
>> works is to create a small port repository similar to René Bertin's
>> `macstrop' repository to override MacPorts with dummy ports.  My
>> question was whether macports itself provides a simpler solution
>> similar to `texlive-dummy-opensuse', where I have to install just a
>> single .rpm file...  I guess the answer is no.
> 
> Its quite simple.  The macports build of lilypond should be
> configured to use the MacPorts provided builds of TexLive.

I was still unclear, sorry.  To continue with lilypond as an example:
This program uses only TeXLive *programs* and data, but no libraries.
In general, this is true for all other programs within MacPorts that
depend on texlive ports.  It is thus irrelevant whether MacPorts
itself contains the necessary data and binaries, or whether they are
provided externally (in this case, by the native TeXLive
distribution).

> If these ports do not provide what is needed, then just provide an
> additional port for what is missing.

There are no misses.  My `problem' is that the `texlive-*' ports
within MacPorts use a few GByte, doubling everything native TeXLive
already provides!  I want to use native TeXLive directly so that I can
actually call `tlmgr' (or the SVN repository) to update the TeX stuff.
For this reason I want to have some dummy portfiles to make `port'
believe that the `texlive-*' ports are present.  This will take a few
kBytes only...


Werner

Re: TeXLive distribution and macports

[Christopher Jones]

> On 9 Sep 2018, at 4:46 pm, Werner LEMBERG  wrote:
> 
> 
>>> [...] For example, I want to create a replacement for
>>> `texlive-basic' that does nothing except fulfilling the dependency.
>>> This is, after installing this dummy `texlive-basic', `port' shall
>>> believe that `texlive-basic' is indeed installed.
>>> 
>>> Ditto for all other `texlive-*' ports.  Ideally, I would like to
>>> have all this stuff in a single file, to be automatically created
>>> from the actual list of `texlive-*' ports as in
>>> texlive-dummy-opensuse,
>>> cf. 
>>> https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
>>> and following lines.
>> 
>> Then I am not sure what you intention here is.
>> 
>> Note that MacPorts has a policy of not using external libraries, as
>> far as possible (apart from obvious system ones) so if you aim is to
>> have a port that basically allows something externally externally to
>> pretend to be something MacPorts provides, then no this is strictly
>> not allowed. See for instance
>> 
>> https://trac.macports.org/wiki/FAQ#ownlibs 
>> 
>> 
>> its the same deal as why we do not support using anything installed
>> outside of MacPorts, from /usr/local
> 
> Ah, I assumed too much knowledge, sorry.  TeXLive itself comes with
> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and
> recent versions, i.e., 10.10-10.13).  By simply prepending the path to
> those binaries to PATH, the `texlive-*' ports from MacPorts would be
> completely hidden and thus useless, more or less: TeXLive wouldn't use
> any data, binaries, or libraries from MacPorts.
> 
> However, to build various packages like `lilypond', `port' needs to
> believe that some `texlive-*' ports are installed.  What certainly
> works is to create a small port repository similar to René Bertin's
> `macstrop' repository to override MacPorts with dummy ports.  My
> question was whether macports itself provides a simpler solution
> similar to `texlive-dummy-opensuse', where I have to install just a
> single .rpm file...  I guess the answer is no.

Its quite simple. The macports build of lilypond should be configured to use 
the MacPorts provided builds of TexLive. If these ports do not provide what is 
needed, then just provide an additional port for what is missing.

Chris

> 
> 
>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: TeXLive distribution and macports

[Christopher Jones]

Hi,

Then I am not sure what you intention here is.

Note that MacPorts has a policy of not using external libraries, as far as 
possible (apart from obvious system ones) so if you aim is to have a port that 
basically allows something externally externally to pretend to be something 
MacPorts provides, then no this is strictly not allowed. See for instance

https://trac.macports.org/wiki/FAQ#ownlibs 


its the same deal as why we do not support using anything installed outside of 
MacPorts, from /usr/local

cheers Chris


> On 9 Sep 2018, at 3:46 pm, Werner LEMBERG  wrote:
> 
> 
>> If I understand what you are asking correctly, you are asking how to
>> setup a port that does nothing other than depend on other ports, so
>> installing it drags in all the dependencies, in one go?
> 
> No, I want the opposite.  For example, I want to create a replacement
> for `texlive-basic' that does nothing except fulfilling the
> dependency.  This is, after installing this dummy `texlive-basic',
> `port' shall believe that `texlive-basic' is indeed installed.
> 
> Ditto for all other `texlive-*' ports.  Ideally, I would like to have
> all this stuff in a single file, to be automatically created from the
> actual list of `texlive-*' ports as in texlive-dummy-opensuse,
> cf. 
> https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
> and following lines.
> 
>> If so we have plenty of these in MacPorts.  [...]
> 
> Thanks; I've already seen such meta-packages.  One of them is actually
> `texlive' itself :-)
> 
> 
>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: TeXLive distribution and macports

[Werner LEMBERG]

> If I understand what you are asking correctly, you are asking how to
> setup a port that does nothing other than depend on other ports, so
> installing it drags in all the dependencies, in one go?

No, I want the opposite.  For example, I want to create a replacement
for `texlive-basic' that does nothing except fulfilling the
dependency.  This is, after installing this dummy `texlive-basic',
`port' shall believe that `texlive-basic' is indeed installed.

Ditto for all other `texlive-*' ports.  Ideally, I would like to have
all this stuff in a single file, to be automatically created from the
actual list of `texlive-*' ports as in texlive-dummy-opensuse,
cf. 
https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
and following lines.

> If so we have plenty of these in MacPorts.  [...]

Thanks; I've already seen such meta-packages.  One of them is actually
`texlive' itself :-)


Werner

Re: TeXLive distribution and macports

[Christopher Jones]

Hi,

If I understand what you are asking correctly, you are asking how to setup a 
port that does nothing other than depend on other ports, so installing it drags 
in all the dependencies, in one go ? If so we have plenty of these in MacPorts. 
The first that springs to mind for instance is

https://github.com/macports/macports-ports/blob/master/x11/xorg-proto/Portfile 


One trick is the port has to install *something* in order to work, for instance 
with the binary tarballs. A common trick is to create a README or similar…

cheers Chris

> On 9 Sep 2018, at 3:16 pm, Werner LEMBERG  wrote:
> 
> 
> My computer for daily use is an openSuSE GNU/Linux box; for TeX
> processing, however, I'm directly using tlmgr.[*] Regardless of this I
> don't have any dependency issues with `zypper', openSuSE's package
> manager, since I'm using the nifty `texlive-dummy-opensuse' package,
> 
>  https://github.com/rolfn/texlive-dummy-opensuse.git   .
> 
> This package tells zypper that all TeXLive packages provided by
> openSuSE are installed, without installing them actually.
> 
> I would like to have something similar for MacPorts.  My questions:
> 
> * Has anyone already written such a dummy package?
> 
> * If not, how can I construct `empty packages' that only exist to
>  fulfill package dependencies?
> 
> 
>Werner
> 
> 
> [*] To be more precise, I don't use tlmgr at all but directly
>TeXLive's SVN repository.  However, this distinction doesn't
>matter here.



smime.p7s
Description: S/MIME cryptographic signature

TeXLive distribution and macports

[Werner LEMBERG]

My computer for daily use is an openSuSE GNU/Linux box; for TeX
processing, however, I'm directly using tlmgr.[*] Regardless of this I
don't have any dependency issues with `zypper', openSuSE's package
manager, since I'm using the nifty `texlive-dummy-opensuse' package,

  https://github.com/rolfn/texlive-dummy-opensuse.git   .

This package tells zypper that all TeXLive packages provided by
openSuSE are installed, without installing them actually.

I would like to have something similar for MacPorts.  My questions:

* Has anyone already written such a dummy package?

* If not, how can I construct `empty packages' that only exist to
  fulfill package dependencies?


Werner


[*] To be more precise, I don't use tlmgr at all but directly
TeXLive's SVN repository.  However, this distinction doesn't
matter here.