| Summary: | treeclean request: app-text/dvibook, app-text/{x,}dvipdfm{,x} | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | TeX project <tex> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cjk, printing, qa, treecleaner |
| Priority: | Normal | Keywords: | PMASKED |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 605728 | ||
|
Description
Michał Górny
2017-08-24 15:34:34 UTC
(In reply to Michał Górny from comment #0) > All of those packages look ancient and pretty much dead. Considering that > texlive-core blocks (replaces?) all of them, is there a point in keeping > them? They are ancient and dead. Not all tl-core versions replace them. When that's the case, feel free to pkgmove them to tl-core and git rm them. You can't pkgmove packages into an existing package. Or move two packages into the same package. (In reply to Michał Górny from comment #2) > You can't pkgmove packages into an existing package. Or move two packages > into the same package. Since when and why ? Since always. It was never pkg *merge*. Moving multiple packages into one means requesting PM to create multiple packages with identical CPV which is technically invalid and can cause mayhem. (In reply to Michał Górny from comment #4) > Since always. It was never pkg *merge*. Moving multiple packages into one > means requesting PM to create multiple packages with identical CPV which is > technically invalid and can cause mayhem. The 'why' is very important then. This seems to be no more than your own interpretation. Citing PMS: 4.4.4 The updates directory The updates directory is used to inform the package manager that a package has moved categories, names, or that a version has changed SLOT. It contains one file per quarter year, named [1-4]Q-[YYYY] for the first to fourth quarter of a given year, for example 1Q-2004 or 3Q-2006. The format of each file is again line-based, with each line having one of the following formats: move <qpn1> <qpn2> slotmove <spec> <slot1> <slot2> The first form, where qpn1 and qpn2 are qualified package names, instructs the package manager that the package qpn1 has changed name, category, or both, and is now called qpn2. The second form instructs the package manager that any currently installed package version matching package dependency specification spec whose SLOT is set to slot1 should have it updated to slot2. Any name that has appeared as the origin of a move must not be reused in the future. Any slot that has appeared as the origin of a slot move may not be used by packages matching the spec of that slot move in the future. Nowhere do I see that doomsday mayhem you're talking about, except when multiple identical origins appear which is not the case here. Alexis, we've been there already. PMS is not foolproof. It assumes people will either have enough imagination to understand the mayhem you could cause, or not enough to invent such a use case. Yes, we will update devmanual on this, just so you could stop arguing for the arguing's sake. However, I would really appreciate if you stopped this 'my interpretation is better than your interpretation nonsense'. I have better things to do than prove anything to you. (In reply to Michał Górny from comment #6) It seems you're not getting it. I'm not arguing at all. I have absolutely never checked pkgmoves I've done had non colliding destinations, thus probably added quite a few that way, and never heard it causing any single problem. If you have found it to be problematic, it shouldn't be hard for you to explain it why. Failing that, I will continue to follow PMS restrictions. Suppose a user has both dev-texlive/texlive-langdanish-2012 and dev-texlive/texlive-langswedish-2012 installed, and his package manager will see the following updates: move dev-texlive/texlive-langdanish dev-texlive/texlive-langeuropean move dev-texlive/texlive-langswedish dev-texlive/texlive-langeuropean Presumably, the first of them will succeed and move the tl-langdanish package to dev-texlive/texlive-langeuropean-2012. However, what shall the poor package manager do for the second package move? In the best case, that move will simply fail. If it succeeds, it will overwrite the VDB entry of dev-texlive/texlive-langeuropean-2012 which means that the files belonging to the former tl-langdanish package will become orphans. (In reply to Ulrich Müller from comment #8) > Suppose a user has both dev-texlive/texlive-langdanish-2012 and > dev-texlive/texlive-langswedish-2012 installed, and his package manager will > see the following updates: > > move dev-texlive/texlive-langdanish dev-texlive/texlive-langeuropean > move dev-texlive/texlive-langswedish dev-texlive/texlive-langeuropean > > Presumably, the first of them will succeed and move the tl-langdanish > package to dev-texlive/texlive-langeuropean-2012. However, what shall the > poor package manager do for the second package move? In the best case, that > move will simply fail. If it succeeds, it will overwrite the VDB entry of > dev-texlive/texlive-langeuropean-2012 which means that the files belonging > to the former tl-langdanish package will become orphans. Indeed, seen that way it is clearly a problem. Are you 100% certain this is how it behaves ? The pkgmoves have always been a bit magic to me: like what happens if I move foo to bar while bar has 4 different slots ? I've always assumed this was a 'virtual' renaming (more like sed in the world and package.use files than vdb mangling) plus install destination package and remove source one. btw, I think I've been doing this since it has been suggested on -dev: https://marc.info/?l=gentoo-dev&m=131805608600917&w=2 (In reply to Alexis Ballier from comment #9) > Indeed, seen that way it is clearly a problem. Are you 100% certain this is > how it behaves ? I've just tested it in a chroot, installing two packages app-misc/foo-1 and app-misc/baz-1. Then I added package move entries for both, moving them to app-misc/quux. Portage does the first move, and silently (!) ignores the second one (with the end result app-misc/quux-1 and app-misc/baz-1). > The pkgmoves have always been a bit magic to me: like what happens if I > move foo to bar while bar has 4 different slots ? I've always assumed this > was a 'virtual' renaming (more like sed in the world and package.use files > than vdb mangling) plus install destination package and remove source one. Nothing "virtual" there, a pkg move is a real VDB update. (In reply to Ulrich Müller from comment #10) > (In reply to Alexis Ballier from comment #9) > > Indeed, seen that way it is clearly a problem. Are you 100% certain this is > > how it behaves ? > > I've just tested it in a chroot, installing two packages app-misc/foo-1 and > app-misc/baz-1. Then I added package move entries for both, moving them to > app-misc/quux. Portage does the first move, and silently (!) ignores the > second one (with the end result app-misc/quux-1 and app-misc/baz-1). Ok. Not that bad but still wrong. > > The pkgmoves have always been a bit magic to me: like what happens if I > > move foo to bar while bar has 4 different slots ? I've always assumed this > > was a 'virtual' renaming (more like sed in the world and package.use files > > than vdb mangling) plus install destination package and remove source one. > > Nothing "virtual" there, a pkg move is a real VDB update. Thanks for the clarification. PMS should probably be amended because I don't see how it can even work if destination pkg has several slots and no slot is specified in the move. app-text/dvipdfmx and app-text/dvipdfm are blocking EAPI3 removal. Can we proceed to last rite them? (In reply to Harri Nieminen (Moiman) from comment #12) > app-text/dvipdfmx and app-text/dvipdfm are blocking EAPI3 removal. Can we > proceed to last rite them? Yes. All stable arches are on texlive versions that replace them. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff8eb7445b9fbaadfcffe1b0b7f4127e284d5423 commit ff8eb7445b9fbaadfcffe1b0b7f4127e284d5423 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2017-12-25 22:09:09 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2017-12-25 22:10:13 +0000 package.mask: Mask app-text/dvibook, app-text/{x,}dvipdfm{,x} for removal Bug: https://bugs.gentoo.org/628820 profiles/base/package.use.mask | 5 +++++ profiles/package.mask | 8 ++++++++ 2 files changed, 13 insertions(+)} @Alexis: how about finially dropping TL 2012 and 2013? (s390 and sh are functionally dead, and not stable arches anymore anyway.) (In reply to Andreas K. Hüttel from comment #15) > @Alexis: how about finially dropping TL 2012 and 2013? > > (s390 and sh are functionally dead, and not stable arches anymore anyway.) I was rather waiting for hppa to stabilize 2016 because some packages have 2012-2015 version ranges These all have been cleaned by dilfridge. |