I looked into what would need to be done to package separately. It still
needs metapost and luatex, which makes it a pain to separate.

Making ls-R at fake time might be possible, but how would you deal with
different subsets being installed? As long as we make sure external ports
only ever install into texmf-local, we can dump a "full" ls-R in for texmf
and texmf-dist and hash only texmf-local at install time when it changes?

Sadly, IIRC, it looks like context uses a single database file under
texmf-var, although i would have to check this (currently on a train).
On Dec 18, 2011 8:52 PM, "Matthias Kilian" <[email protected]> wrote:

> On Sun, Dec 18, 2011 at 01:00:01AM +0000, Edd Barrett wrote:
> > > For context, I assume it lives in one specific package, so you could
> > prepare
> > > it and stuff it in the package.
> >
> > I was not working under this assumption, but you might get away with it.
> If
> > new packages start installing context crap, then we would have to change
> > our plan ofcourse...
> >
> > Also I will look into making a separate port.
> >
> > Kili, what do you think about all of this?
>
> I don't know about context, but if it's so special that it not even
> uses libkpathsea, it should really go at least into a separate
> package and (if possible) live outside of the texmf* hierarchies
> of the texlive packages.
>
> For generating any `databases' (like the ls-R files in the texmf
> directories), it would be nice if this could be done at the fake
> stage, so the ls-R files are just perfectly ordinary files in the
> plist. For other (non-texlive) stuff, we already have texmf-local,
> right?
>
> Ciao,
>        Kili
>

Reply via email to