Respect repository pinning

[krono]

tlmgr now has the possibility to pin packages to certain repositories. That way, updates from the command-line prefer packages from specified repositories over others. (Example from KOMA-Script:

tlmgr repository add http://www.komascript.de/~mkohm/texlive-KOMA KOMA
tlmgr pinning add KOMA koma-script
tlmgr install --reinstall koma-script

Adds a named repository “KOMA” and pinns the packages koma-script to that repository)

Currently, tlutility does not support that, instead updating pinned packages whenever the current repository has a higher “version”.

[amaxwell]

That's not good; I'm fairly sure Norbert said that as long as I passed --repository on all install/update actions (I do), the pinned package wouldn't be overwritten.

[krono]

Oh. Yet, I observe that KOMA-Script (as pinned above, currently version '3.13.…') is overwritten by the texlive-variant (still '3.12' but higher “internal version number”)

[amaxwell]

Understood. My vague recollection is just that I didn't have to do any special coding to keep this sort of thing from happening, so I've sent an email to Norbert (the tlmgr maintainer) to check. Thanks for the report!

[krono]

Nice.

PS: just installing without a --repository argument via tlmgr respects the pinning

[norbusan]

Hi Adam,
I don't remember having said that using -repository in combination with pinning will work out.

Yes, passing -repository switches tlmgr to single-repo-mode (old mode), and thus pins are lost.

I will think about how this can be treated, but we don't want old pins to remain, actually tlmgr will warn about that.

I think a good idea would be that, if tlutility uses an installation with multiple sources, then it does not pass the -repository option. I think this is the safest bet.

[krono]

I really would like

• A Repository management (ie, seeing which repositories tlmgr knows about by which name)

• A Pining management

  in tlutility. Should I make this new issues?

[norbusan]

You can always use tlmgr gui (if you have perl/tk installed) to get a repository GUI handling

[krono]

(I happen to not have perl/tk installed. Other than that I find the integration of the tlutility a more pleasant experience, but I don't think this helps here :). Anyway, thanks for the pointer)

[amaxwell]

Hi Norbert,

thanks for the response. I dug through my inbox and found the message I was thinking of:

On Mi, 25 Apr 2012, Adam R. Maxwell wrote:
> Can you suggest what I might want to try?  I always pass an explicit
> location, if that matters...

Yes it matters. With an explicit location it always goes into
single database mode, so nothing changed ;-)

Apparently we misunderstood each other! This is the reason I never did anything about pinning support :). I cannot omit the --location argument; that's a key feature. Is there something in tlmgr update --list --machine-readable that will tell me if a package is pinned? I could at least omit it from update actions or flag it somehow. The manual page doesn't indicate any changes to the output, though.

[krono]

If it helps, here's my output of tlmgr update --list --machine-readable:

location-url    http://mirror.ctan.org/systems/texlive/tlnet http://www.komascript.de/~mkohm/texlive-KOMA
tlmgr: package repositories:
    main = http://mirror.ctan.org/systems/texlive/tlnet
    KOMA = http://www.komascript.de/~mkohm/texlive-KOMA
total-bytes 11650908
end-of-header
dad u   35139   35143   482675  -   -   main    1.0 1.0
fbb u   34359   35144   2019431 -   -   main    1.05    1.06
koma-script u   1784    1789    6816374 -   -   KOMA    3.13.1784   3.13.1789
lettre  u   31879   35145   477187  -   -   main    2.349   2.353
texlive-docindex    u   35136   35141   211359  -   -   main    -   -
xepersian   u   35133   35146   1006856 -   -   main    14.5    14.6
pressrelease    a   -   35147   632552  -   -   main    -   -
collection-latexextra   u   35134   35147   4474    -   -   main    -   -
end-of-updates

You can see that the default repo seems to be main and that koma-script hase KOMA somewhere.

@norbusan I noticed that the machine-readable format as explained in tlmgr help does not match the output above. All fields after esttot are missing in the description.

[amaxwell]

Reading the tlmgr manual, even if I add support for pinning actions, I'd still need a way for update actions with a --repository to not update/install pinned packages. Something like --exclude-pinned, perhaps.

[amaxwell]

@krono, the last two columns are catalogue version numbers (which @norbusan added at my request; I use them in TLU), and an old e-mail says that the other column is a 'tag'. TLU ignores runtime/esttot/tag, and tag is always a dash here. It appears that if tag is not main && not -, then it's pinned?

[krono]

seems so

[norbusan]

Adam, yes that `tag' is what is the name of the repository. There are three options for it:

• `-' then we are in single repo mode (like when giving --repository ..)
• `main' we have multiple repos, and the package is coming from the main repo
• anything but the above: the tag (name) or URL of an additional repository.

But I don't know if that helps you, as you are always calling with --repository.

Concerning the question about having something like `--exclude-pinned' : I think about it, but maybe there is a way with the current methods?

[amaxwell]

@norbusan, if update --list --repository=http://foo.bar --machine-readable tells me that an update would be from an additional repo, I might be able to hack a solution by explicitly passing all package names for update on the command line. The problem is that I'll end up hitting argument limits eventually. If it will always give -, then I am SOL.

There are historical (and good) reasons why I always pass --repository, so there's no way to stop doing that. It avoids problems with the multiplexor, in particular, and is pretty solidly integrated into TLU's design.

[amaxwell]

Well, after installing koma-script as described above, it looks like passing --repository means that I'll always see a dash for the tag. Apparently the only way to figure out which packages are pinned is by parsing the output of tlmgr pinning. Is this correct?

[norbusan]

Hmm, I was thinking about how I can implement --exclude-pinned, but this is nasty: We allow for globs in the pinning file, like tlptexlive:*. But then, for knowing which packages are actually pinned, we need to load the actual database.

That means, whatever we do at the moment, using --repository will not easily work.

My proposal is that I implement --repository to allow for multiple repositories. Then you could do:

• get the list of current repositories
• if the main one is mirror, select one without multiplexer
• pass all repositories to the tlmgr call
  You would still to have implement some way to parse the list of repositories `tlmgr repository list' including the tags, as both can be used in the pinning file.

Would that work?

[amaxwell]

@norbusan, I'll keep thinking about this. I never pass the multiplexer as --repository, which I think answers your second point? On the other hand, TLU's main repository isn't necessarily the same as tlmgr's main repository, so I'd have to resolve conflicts in that case.

I'm not in too much of a hurry on this, as I suspect that most TLU users aren't using pinning (with apologies to @krono) or even know what it is. At this point, I'd just like to come up with a way to keep from messing up a pinned package, and I can probably do that as-is with some work.