diff options
Diffstat (limited to 'Master/tlpkg/dev')
| -rw-r--r-- | Master/tlpkg/dev/dev.multi-source-support-v2.README | 169 |
1 files changed, 0 insertions, 169 deletions
diff --git a/Master/tlpkg/dev/dev.multi-source-support-v2.README b/Master/tlpkg/dev/dev.multi-source-support-v2.README deleted file mode 100644 index 513b8daf5c5..00000000000 --- a/Master/tlpkg/dev/dev.multi-source-support-v2.README +++ /dev/null @@ -1,169 +0,0 @@ -Multi source support in TeX Live v2 ------------------------------------ -(Work in progress) - -[needs dev.merge-tlmedia-into-tlpdb-and-get-rid-of-it !!!! ] - -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. - -Old discussion: - -[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. - -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 - -[NOT IMPLEMENTED BY NOW] -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 ;-) ] |