ho-tex / oberdiek

Updating the oberdiek bundle
Other
16 stars 6 forks source link

Missing packages after latest updates #77

Closed w5l closed 4 years ago

w5l commented 4 years ago

Not sure if this is the right location for this issue, but CTAN "oberdiek" links to this repository and I see a lot of updates last few days. Apologies if I've come to the wrong location.

I just ran a TeX (MikTeX/Windows) package update which broke compilation for many documents. It seems the universally used package kvoptions is no longer available. I can find it on CTAN but the package installer cannot locate it. The same issue happens with stringenc.

Tried using multiple CTAN repository mirrors, and reproducible with a clean install of everything TeX related.

It seems you are migrating packages away from the all-inclusive overdiek package? If so, a good move in my opinion 👍

For now I've manually downloaded and installed the missing packages in my distribution and that has resolved the issue.

u-fischer commented 4 years ago

Unlike texlive miktex doesn't autoinstall new packages. In miktex you have to manually update your package database in the miktex console. Then miktex will be able to find new packages. Do it in user and admin mode.

image

But it looks as if miktex has only updated oberdiek but not installed kvoptions. You should report this as issue in the miktex issue tracker.

TerenceWSK commented 4 years ago

A lot of scientific journal templates rely on the old all-inclusive package. Migrating out has so far, caused a lot of troubles.

davidcarlisle commented 4 years ago

@TerenceWSK sorry I don't understand that comment very few end users should be installing ctan packages like "oberdiek" , so should not be affected by this. Perhaps in miktex they may need to update (it may be that miktex can make that more automatic) but certainly in texlive it should be transparent for most uses.

But in any case splitting is essential if those journals want to be using supported software.

Maintaining the oberdiek bundle as it was with 95 separate packages and taking over an hour just to typeset the documentation to repackage the bundle after any change to any package is not sustainable given the volunteer resources available for maintaining his code.

The scientific journals may need one or two parts of oberdiek so will (eventually) benefit from the split, they do not need to force their users to have packages that haven't worked for years (luatex) or stopped working as the code they are patching changed (grffile) or include massive 100 page manuals for packages that they probably never use (inputex) etc.

w5l commented 4 years ago

I know about the Tasks > Update package DB requirement, it didn't help in this case. Sorry, I should've mentioned.

Very few end users should be installing ctan packages like "oberdiek"

It might have appeared because of another package referring to it? None of the documents here reference that package directly, but who knows where the layered dependencies end up.

But it looks as if miktex has only updated oberdiek but not installed kvoptions. You should report this as issue in the miktex issue tracker.

Ah, MikTeX keeps it's own index? I was unaware of that, thanks. I thought it accessed CTAN directly.

Edit Checked the MikTeX package DB and it is indeed not showing kvoptions. Since that is the root of this issue, I would consider it closed, unless you feel like continuing the discussion about the merits of one giant package versus many small ones 😉 Good luck on the migration.

davidcarlisle commented 4 years ago

Very few end users should be installing ctan packages like "oberdiek"

It might have appeared because of another package referring to it? None of the documents here reference that package directly, but who knows where the layered dependencies end up.

There is no latex package called oberdiek and no document can ever reference it. oberdiek is just a device used by ctan and texlive/miktex to install 95 separate latex packages in one go. So it should have very little effect on end users, this is just a question of packaging for distribution and installation.

Having all the packages in one bundle really only has downsides, it imposes a massive maintenance overhead on the volunteers maintaining the thing, and for users trying to install a minimal tex installation for custom uses it meant they had to install all of it if they needed any, and most users, who install all packages anyway, it makes no difference whether pdftexcmds is oberdiek/pdftexcmds.sty or, as now pdftexcmds/pdftexcmds.sty

There may be some transient issues during the re-arrangement which is unfortunate, but the end result will certainly be better.

But in any case thanks for your best wishes, I'll close this as suggested.

w5l commented 4 years ago

Sorry to add to the closed issue, but MikTeX definitely shows an "oberdiek" package, and the two machines with MikTeX that I have access to right now both show that it's "installed", for whatever reason. Not an issue with this repository, of course, but maybe interesting to know in case of future issues.

u-fischer commented 4 years ago

@willemduncan "oberdiek" is still there but it is getting smaller as packages are split out of it. (It did contain so many packages that it has to be done in steps).

u-fischer commented 4 years ago

@willemduncan and there is already a bug report on the miktex site: https://github.com/MiKTeX/miktex-packaging/issues/145

TerenceWSK commented 4 years ago

@davidcarlisle Thank you for replying.

I still have something to add. I don't know if this issue is with MikTeX or the newly updated oberdiek. The journal's template I mentioned keep prompting that I should install oberdiek which I have already installed (and I tried to uninstall this bundle and re-install, without any luck fixing this problem, and Tasks > Update package DB does not fix the problem either).

The PDF compiler keeps telling me that it is missing components from oberdiek (among which some are migrated out and some are still included in the latest oberdiek). The corresponding folder for oberdiek in the MikTeX installation route is empty, and I don't know whether this has something to do with the update. Manually downloading oberdiek and use tex command to create sty files is successful. The template needs 20+ oberdiek components which are reported "missing" (many of them are currently still IN oberdiek), which is a headache. It seems that after this update, the "package" oberdiek is not correctly installed. Journal templates do not always keep up with the update very soon, and we researchers are not professionals in LaTeX.

davidcarlisle commented 4 years ago

@TerenceWSK one thing I didn't know at the time I made the first reply that as a result of various timing issues, currently (just for today: it is already fixed in sources) miktex has the new oberdiek (without kvoptions) but hasn't got the separated kvoptions package.

Ulrike's answer in the miktex tracker gives a workaround (or it'll fix itself tomorrow)

https://github.com/MiKTeX/miktex-packaging/issues/145

That's unfortunate and as I note in a comment at the end of that miktex issue, I take responsibility for that ultimately. But it is only tangentially related to the decision to split up oberdiek. Any update of a distributed system like the ctan collection of latex contributed packages has multiple opportunities for human error or transient states that are inconsistent.

And in relation to your final comment, very few people are professionals in latex. This is an unpaid "spare time" activity, both for the people maintaining the tex code, and the people handling ctan updates.