Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 628820 - treeclean request: app-text/dvibook, app-text/{x,}dvipdfm{,x}
Summary: treeclean request: app-text/dvibook, app-text/{x,}dvipdfm{,x}
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: TeX project
URL:
Whiteboard:
Keywords: PMASKED
Depends on:
Blocks: EAPI3Removal
  Show dependency tree
 
Reported: 2017-08-24 15:34 UTC by Michał Górny
Modified: 2018-01-23 22:51 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-08-24 15:34:34 UTC
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?
Comment 1 Alexis Ballier gentoo-dev 2017-08-24 19:14:56 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.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-08-24 20:03:00 UTC
You can't pkgmove packages into an existing package. Or move two packages into the same package.
Comment 3 Alexis Ballier gentoo-dev 2017-08-25 08:47:33 UTC
(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 ?
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-08-25 08:59:12 UTC
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.
Comment 5 Alexis Ballier gentoo-dev 2017-08-25 11:28:41 UTC
(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.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-08-25 12:36:13 UTC
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.
Comment 7 Alexis Ballier gentoo-dev 2017-08-25 12:50:37 UTC
(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.
Comment 8 Ulrich Müller gentoo-dev 2017-08-25 13:59:04 UTC
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.
Comment 9 Alexis Ballier gentoo-dev 2017-08-25 14:10:17 UTC
(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
Comment 10 Ulrich Müller gentoo-dev 2017-08-25 17:07:28 UTC
(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.
Comment 11 Alexis Ballier gentoo-dev 2017-08-25 17:14:46 UTC
(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.
Comment 12 Harri Nieminen (Moiman) 2017-11-30 11:04:04 UTC
app-text/dvipdfmx and app-text/dvipdfm are blocking EAPI3 removal. Can we proceed to last rite them?
Comment 13 Andreas K. Hüttel gentoo-dev 2017-12-25 21:59:30 UTC
(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.
Comment 14 Larry the Git Cow gentoo-dev 2017-12-25 22:10:28 UTC
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(+)}
Comment 15 Andreas K. Hüttel gentoo-dev 2017-12-25 22:11:46 UTC
@Alexis: how about finially dropping TL 2012 and 2013? 

(s390 and sh are functionally dead, and not stable arches anymore anyway.)
Comment 16 Alexis Ballier gentoo-dev 2017-12-28 07:01:37 UTC
(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
Comment 17 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2018-01-23 22:51:14 UTC
These all have been cleaned by dilfridge.