Multi source support in TeX Live -------------------------------- (Work in progress) (completely independent from generalized revisions) [karl: good.] 1) extension of the location part in 00texlive-installation.config ------------------------------------------------------------------ Every line can contain an aditional tag ([a-z0-9,]+) after the actual location, examples: depend location:http://mirror.ctan.org/systems/texlive/tlnet/2008 ctan depend location:http://server.local.uni/texlive/packages department done [karl: how do these lines get added? tool, manual editing of tlpdb?] [norbert: tlmgr location url1 url2=tag1 url3 url4=tag2 ... # sets url1, url2 with tag tag1, url3, and url4 with tag2 # as the list of available locations # backward compatibility with former usage tlmgr location add ... # adds locations to the list of available locs tlmgr location remove ... # removes locations ... ] [k2: well, there is no "location" action now, so compatibility isn't an issue. having this new action seems like a good idea. tlmgr option location foo will just become a synonm for tlmgr location add foo. yes?] 2) invocation of tlmgr/installation ----------------------------------- Normally tlmgr will install the candidate with the highest revision number. [karl: ok, given pinning below. otherwise i don't like it.] [norbert: Why, can you explain why you don't like that the highest revision number wins?] [k2: because it is random, except in the one case where you want to use it. that is, i understand that you want to copy a tl package, make some local fixes, and install it locally, keeping track of the rev number. that's fine for you. but there's no way most people are going to bother with that. if mojca sets up a context repo, say, those revision numbers are (should be) completely independent of tl's revision numbers. therefore, all the context packages should be pinned to the context repo, so the context repo always wins. without pinning, it would be an unmaintainable situation.] That will be achieved by tlmgr install package If you want to install a package from a specific mirror you can do tlmgr install package/TAG (tlmgr install package/SOURCE) where TAG is the tag given above, and SOURCE is the full source address. So continuing the above example we could call tlmgr install package/department or tlmgr install package/http://server.local.uni/texlive/packages (maybe we don't allow the later form ...?) [karl: well, if it's done, then I see no reason not to support it.] done 3) pinning ---------- tlmgr will evaluate an additional config file ROOT/tlpkg/pinning or the one given via cmdline tlmgr -pins /path/to/pinning/file [karl: maybe it should be found in texmf-local/tlpkg? look there before ROOT/tlpkg but allow both? maybe other places too. have to think about it. Also, the filename should be something clearer, perhaps tlpkgpins.txt.] [norbert: agreed, that texmf-local might be a better place. should be thought out] That file contains lines package:tag:pin where package is a package name or * (or regexp? or glob context* eg?) [glob is better than regexp in this case I think] and tag is [a-z0-9,]+ as for tags above, or *, and pin is an integer between 0 and 1000. Now the evaluation *which* package will be installed will be done as follows: 1) create the list of candidates, i.e., all tlpobj from different sources where the name matches the one to be installed [karl: if a package is pinned to a single source (99% case, seems to me), the other sources (e.g., default ctan) won't even be considered, right?] [norbert: well, it depends. There will be a default pin value of say 500, and you can give pin values lower than 500 to prefer packages from other sources, or higher pin values to prefer these sources] [k2: I understand there is all this flexibility, but that's not my point. I envision the single most common use of this (by far) to say "get package foo from my special location bar", where foo is a local font, or tlmgr from tlcritical. In these cases, the user will set a single location. And then it would be a waste of time for tlmgr to even consider looking at the default location (tlnet) for foo. It should not even be a candidate.] 2) compute the pins of all the candidates 3) if there are different pins cancel those candidates with a non-maximal pin (i.e., let pin_max = max { pin(candidate) : candidate in candidates }, and new candidates are those with pin(candidate) = pin_max) 4) within all the remaining candidates choose the one with the highest revision number ======================================== Consequences of the above: - no source: part necessary in the revisions - packages can be pinned to a specific source, and will not be updated even if another source ships a higher version number - no changes to the general server infrastructure are needed - default installations continue as before - normal installations with multiple sources but without pinning will simply *do*the*right*thing*, namely install the highest revision number. [karl: it's unclear to me that that is the right thing, in general, but I can see how it is the right thing in some cases, e.g., yours, so fine.] [norbert: see above ... I don't see the wrong point ;-) ]