From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/31500 Path: news.gmane.org!not-for-mail From: Frank =?iso-8859-1?Q?K=FCster?= Newsgroups: gmane.comp.tex.context Subject: Re: ConTeXt on Debian: The wiki entry Date: Tue, 24 Oct 2006 11:01:33 +0200 Message-ID: <86ods25bpu.fsf@alhambra.kuesterei.ch> References: <453D38AD.1010608@wxs.nl> <86hcxufedo.fsf@alhambra.kuesterei.ch> <453DCC3A.40503@wxs.nl> Reply-To: mailing list for ConTeXt users NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1161680533 29968 80.91.229.2 (24 Oct 2006 09:02:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Oct 2006 09:02:13 +0000 (UTC) Cc: mailing list for ConTeXt users Original-X-From: ntg-context-bounces@ntg.nl Tue Oct 24 11:02:10 2006 Return-path: Envelope-to: gctc-ntg-context-518@m.gmane.org Original-Received: from ronja.vet.uu.nl ([131.211.172.88] helo=ronja.ntg.nl) by ciao.gmane.org with esmtp (Exim 4.43) id 1GcIAN-0005iG-RD for gctc-ntg-context-518@m.gmane.org; Tue, 24 Oct 2006 11:01:49 +0200 Original-Received: from localhost (localhost [127.0.0.1]) by ronja.ntg.nl (Postfix) with ESMTP id 677C81FE56; Tue, 24 Oct 2006 11:01:47 +0200 (CEST) Original-Received: from ronja.ntg.nl ([127.0.0.1]) by localhost (smtp.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17625-01-4; Tue, 24 Oct 2006 11:01:41 +0200 (CEST) Original-Received: from ronja.vet.uu.nl (localhost [127.0.0.1]) by ronja.ntg.nl (Postfix) with ESMTP id 7F4441FE58; Tue, 24 Oct 2006 11:01:41 +0200 (CEST) Original-Received: from localhost (localhost [127.0.0.1]) by ronja.ntg.nl (Postfix) with ESMTP id E04111FE5C for ; Tue, 24 Oct 2006 11:01:39 +0200 (CEST) Original-Received: from ronja.ntg.nl ([127.0.0.1]) by localhost (smtp.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17625-01-3 for ; Tue, 24 Oct 2006 11:01:36 +0200 (CEST) Original-Received: from idmailgate1.unizh.ch (idmailgate1.unizh.ch [130.60.127.100]) by ronja.ntg.nl (Postfix) with SMTP id B90D61FE56 for ; Tue, 24 Oct 2006 11:01:36 +0200 (CEST) Original-Received: from localhost (zilnx53.unizh.ch [130.60.127.85]) by idmailgate1.unizh.ch (8.13.7/8.13.7/SuSE Linux 0.7) with ESMTP id k9O91arj025814; Tue, 24 Oct 2006 11:01:36 +0200 Original-Received: from idmailgate1.unizh.ch ([130.60.127.100]) by localhost (virus2.unizh.ch [130.60.127.85]) (amavisd-new, port 10024) with LMTP id 24491-18; Tue, 24 Oct 2006 11:01:34 +0200 (CEST) Original-Received: from localhost ([130.60.169.110]) by idmailgate1.unizh.ch (8.13.7/8.13.7/SuSE Linux 0.7) with ESMTP id k9O91YMn025796 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 Oct 2006 11:01:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by localhost with esmtp (Exim 4.50) id 1GcIA9-0005Wt-PQ; Tue, 24 Oct 2006 11:01:33 +0200 Original-To: Hans Hagen X-Attribution: fant X-Ehrenamt: http://www.langau.de In-Reply-To: <453DCC3A.40503@wxs.nl> (Hans Hagen's message of "Tue\, 24 Oct 2006 10\:18\:02 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: amavisd-new at unizh.ch X-Virus-Scanned: amavisd-new at ntg.nl X-BeenThere: ntg-context@ntg.nl X-Mailman-Version: 2.1.7 Precedence: list List-Id: mailing list for ConTeXt users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: ntg-context-bounces@ntg.nl Errors-To: ntg-context-bounces@ntg.nl X-Virus-Scanned: amavisd-new at ntg.nl Xref: news.gmane.org gmane.comp.tex.context:31500 Archived-At: Hans Hagen wrote: > concerning fmtutil: there was a time that texexec could call fmtutil, > but the lack of engine support (as taco explained, it was a trade off > for simplifying the fmt suffix but part of the bargain was nog kept) > as well as all kind of messy 'aliasing' going on in tex distributions > (leading to dropped patterns and fonts) = Uups, what kind of aliasing? Can you point me to a place where this is discussed? = > made us decide to drop that; > another reason is that distrubutions like texlive more or less assume > a'wipe your system clean and install new' policy which is not possible > if you have aditional trees, run older binaries with newer trees, etc, I know that TeXlive has such an approach, but as I understood it this only extends to the TeXlive system itself: TEXMFLOCAL, TEXMFHOME and any other user-added tree should continue to work. Pool files are a problem, but if ConTeXt has found a way to use for example different versions of pdftex and let each one find its correct pool file, I think this feature should be implemented in TeXlive, too. > which is why texmfstart came around: relocating script paths and > enc/map paths was done in not downward compaible ways (which in turn > is the reason why context ships with all kind of tools to clean up and > reorganize trees etc). Hm, it seems I really need to actually dig into what texmfstart and other ConTeXt scripts do before I can continue. I thought everybody was happy with current TDS, and also that it didn't leave important things unspecified. = > Concerning updmap, as Taco explains in another mail, context does not > use updmap output; this has a long history: > > - context had runtime map loading before updmap was around > - we never used the 'huge map files' because it was real slow (this > was fixed at some point, hash instead of linear search) > - merging map entries in to one big file is dangerous (there can be > multiple instances of fonts, same name, different metrics, same > longname, different font etc) > - we want clean and easy ways to add support for commercial fonts > (which is the majority) > - pdftex and dvipdfmx were adapted to do run time loading > > so, there is no need to spend time on updmap for context. But maybe other formats could profit from ConTeXt's way to do it, too: These arguments seem to apply to LaTeX and whatever else, too. > I have no idea what texconfig does but i don't think context needs it > (i may be wrong). I never need it... It's just a textmode-menu interface to things like editing language.dat (hyphenation patterns for latex and relatives), calling updmap, changing dvips defaults, etc. >> I'm not sure what you mean. The default TEXMF path for teTeX (and I >> think also for TeXlive) is >> >> TEXMF =3D {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TE= XMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST} >> = > the problem with texmf is that there can be many variants, and there > have been in the past; here i now have: > > TEXMF=3D{!!$TEXMFPROJECT,!!$TEXMFFONTS,!!$TEXMFLOCAL,!!$TEXMFEXTRA,!!$TEX= MFMAIN} > > texmfproject : a tree for project related files, these will not be > wiped out with an update > texmffonts : a safe place for commercial fonts, also not being > wiped out (may have older tds structures) > texflocal : the place for updates and specific user settings > texmfextras : introduced a few years ago in texlive for non free > stuff (first dvd productions) > texmfmain : on my system a mere copy of the latest tex live, just > the whole lot So you don't use TEXMFVAR and user-specific trees? Anyway, I still fail to see how that's a problem for context updates. The natural approach seems to be - check whether context already exists anywhere except texmfmain (where the update can't go because of the wiping out) - if yes, check whether the directory is writable - if one answer was no, ask the user where to put it. > interesting is that a request for texmfproject and texmffonts on the > tex live list was rejected by tetex folks because they didn't want > extra paths, but see what extra paths tetex adds -) The extra paths that teTeX (and TeXlive too) add are paths with a particular role for each. From what you told me so far, I don't see what the difference between TEXMFPROJECT, TEXMFFONTS, TEXMFEXTRA and TEXMFLOCAL is, and why it is a problem for ConTeXt updates that individual admins might add trees. > concerning tex live: i must admit that i only copy the tree and use a > much simplified texmf.cnf file which as a side effect makes tex run > faster That's an interesting point, in particular for us Debian people: We have split up texmf.cnf in individual parts (for reasons that don't matter here), and we might be able to provide a minimal texmf.cnf like yours if texlive-latex is not installed, but texlive-context is. > sure, but the fact that the 'real' names change every now and then > makes it hard for users to cary a history around without renaming; > also, one of the ideas behind tds and web2c was that platforms could > share trees, which is what i like: i have one set of trees for running > all platforms (so, texmf-local it is here) That's not so much of a problem in Debian, because the package managment system will respect your changes and always keep texmf-local if you like. But generally I agree that this is suboptimal. >> AFAIK only the search path for texmf.cnf is hard-coded, and that can't >> be avoided. On the other hand, no one ever approached me and requested >> a relocation: What would you want, and in which cases? >> = > i think that there are a few more paths in there (you sometimes see > them in var expansions, but normally they don't hurt) ; life would be > easier if texmfcnf was always taken from an env var; actually, i set > all important env vars anyway, if only because it isolates tex > distrubutions (after all we're talking about a only a few vars than > determins all); = I trust you to do it right, but we've had a couple of bogus bugreports from people who set env vars wrongly, or completely forgot they ever had... = I'll see that I or Norbert Preining look into this and come back with a more constructive proposal. Regards, Frank -- = Dr. Frank K=FCster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Z= =FCrich Debian Developer (teTeX/TeXLive)