1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
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 ;-) ]
|
