summaryrefslogtreecommitdiff
path: root/Master/tlpkg/doc
diff options
context:
space:
mode:
authorNorbert Preining <preining@logic.at>2012-04-17 04:12:01 +0000
committerNorbert Preining <preining@logic.at>2012-04-17 04:12:01 +0000
commitb91e9ddd28b2917ca284456b2e14e2bee80e1e4f (patch)
tree0757a11b7992d1f9cfc33ea5d0c081727a84c2f0 /Master/tlpkg/doc
parent86d7c60c406474fa856d8f87d69c7fa52ccacb1b (diff)
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
Diffstat (limited to 'Master/tlpkg/doc')
-rw-r--r--Master/tlpkg/doc/multi-repository.txt151
1 files changed, 151 insertions, 0 deletions
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 ;-) ]