From b91e9ddd28b2917ca284456b2e14e2bee80e1e4f Mon Sep 17 00:00:00 2001 From: Norbert Preining Date: Tue, 17 Apr 2012 04:12:01 +0000 Subject: move the multi-repo README to the doc dir, and mark it as old development notes git-svn-id: svn://tug.org/texlive/trunk@26005 c570f23f-e606-0410-a88d-b1316a301751 --- Master/tlpkg/doc/multi-repository.txt | 151 ++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 Master/tlpkg/doc/multi-repository.txt (limited to 'Master/tlpkg/doc') diff --git a/Master/tlpkg/doc/multi-repository.txt b/Master/tlpkg/doc/multi-repository.txt new file mode 100644 index 00000000000..ca1192e080b --- /dev/null +++ b/Master/tlpkg/doc/multi-repository.txt @@ -0,0 +1,151 @@ +Multi source support in TeX Live v2 +----------------------------------- +DEVELOPMENT NOTES -- SEE THE MANUAL PAGE OF TLMGR FOR CORRECT STATUS +===================================================================== + +v2 of this patches has changed completely the idea of implementation. +Background of the new idea is to leave the code base of tlmgr.pl itself +as untouched as possible, and merge everything into TLPDB. TLPDBs can +now either be a normal one as before, or a virtual one, collection +different sources. + +(completely independent from generalized revisions) +[karl: good.] + +1) extension of the location part in 00texlive.installation +----------------------------------------------------------- + +The opt_location: line in 00texlive.installation normally gives the +repository to be used. It can now contain a list of repositories in the +form + repo1[#tag1] repo2[#tag2] ... + +Management of these items is thorugh + tlmgr repository +action. + tlmgr repository list + tlmgr repository add repo [tag] + tlmgr repository remove name +If no tag is given then internally (but not in the tlpdb) the tag +and the repo path is the same. + +Removing is done by entering the tag (not the repo), but if no tags were +given that is the same. + + +If there are more than one tag, then there has to be one tagged + main +which is the main repository. + +By default, if you start with only one entry (as before, the main), +and add a new one, the tag "main" is automatically added to the +previous tag to make all run smooth. + +THe repo at "main" is used for various settings, the main configuration +options, etc etc. Idea is still that everyone has the main repo CTAN +(or mirror or ...), and can add some sub-repos. + +2) invocation of tlmgr/installation +----------------------------------- + +Normally tlmgr will install the candidate with the highest revision number. + +This is controlled by + TLPDB::virtual_candidate +For now the policy is the highest rev number, but we can add later +different policies. + +[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 + +[FOR NOW THE FOLLOWING IS NOT IMPLEMENTED!!] +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 ;-) ] -- cgit v1.2.3