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
|
Multi source support in TeX Live
--------------------------------
(Work in progress)
(completely independent from generalized revisions)
[karl: good.]
1) extension of the location part in 00texlive-installation.config
------------------------------------------------------------------
Every line can contain an aditional tag ([a-z0-9,]+) after the actual location,
examples:
depend location:http://mirror.ctan.org/systems/texlive/tlnet/2008 ctan
depend location:http://server.local.uni/texlive/packages department
done
[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.
[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
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 ;-) ]
|
