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

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 ;-) ]