search

vaeth / eix

eix can access Gentoo portage ebuild information and description very quickly (using a local cache). It can also be used to access information on installed packages, local settings, and local and external overlays, and informs about changes in the tree
GNU General Public License v2.0
164 stars 13 forks source link

eix doesn't understand -r0 #103

Closed ajakk closed 1 year ago

ajakk commented 1 year ago

eix doesn't see 3.15 of mic-paren as masked:

$ eix -e mic-paren
* app-emacs/mic-paren
     Available versions:  3.13 (~)3.15
     Homepage:            https://www.gnuvola.org/software/j/mic-paren/ https://www.emacswiki.org/emacs/MicParen
     Description:         Advanced highlighting of matching parentheses

However, Portage does:

!!! All ebuilds that could satisfy "=mic-paren-3.15-r0" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-emacs/mic-paren-3.15::gentoo (masked by: package.mask, ~amd64 keyword)
/var/db/repos/gentoo/profiles/package.mask:
# Ulrich Müller <ulm@gentoo.org> (2021-04-20)
# Version 3.15 is broken with Emacs 27.2.

It seems like there's a Portage bug making the actual line of masking not appear above. The actual atom is:

$ grep mic-paren package.mask
=app-emacs/mic-paren-3.15-r0
ajakk commented 1 year ago

Hm. That's not a Portage bug, I guess I misremembered the mask message formatting.

vaeth commented 1 year ago

eix intentionally considers versions with different string representations differently, as it is possible to have ebuilds with two such versions on disk. I know that this is strictly speaking a violation of pms, but this seems a reasonable price to me for displaying everything which is on disk.

ajakk commented 1 year ago

I don't understand why that makes it make sense to misrepresent the state of package.mask.

vaeth commented 1 year ago

It is about the presentation of package versions. Supporting some questionable corner case (naming the version in the ebuild with a different string representation than in the package mask) is not worth to break the whole versioning logic which provides the possibility of having two ebuilds with different string representations of the same version. The latter does perhaps not make sense for a package manager, but it makes sense for a tool which displays the packages and their versions. Sure, with much cumbersome logic one might support this corner case, but it is not worth the effort. Moreover, it is also about speed: Using version comparisons in package.* files is much slower than using a string lookup in a hash table or sorted tree.