summaryrefslogtreecommitdiff
path: root/Master/tlpkg/dev
diff options
context:
space:
mode:
Diffstat (limited to 'Master/tlpkg/dev')
-rw-r--r--Master/tlpkg/dev/dev.multi-source-support-v2.README169
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 ;-) ]