| Summary: | Ebuilds are using KEYWORDS="-*" instead of KEYWORDS="" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mike Kelly (RETIRED) <pioto> |
| Component: | New packages | Assignee: | Gentoo Quality Assurance Team <qa> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cretin, dholm, ebo, hanno, media-video, pam-bugs+disabled, parallelgrapefruit, robbat2, sandbox, sgtphou, steev |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://devmanual.gentoo.org/keywording/index.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Mike Kelly (RETIRED)
2007-01-06 17:05:46 UTC
Provide a method to state "This ebuild is untested on all arches and thus is not guaranteed to work on any of them." then. This should cover all of CVS versions. Then it should either be in package.mask or not in the tree at all. Vapier, you're the largest user of KEYWORDS="-*"; you should follow this bug. Genone, would a KEYWORD="~unsupported", plus p.mask, be practical for you? (In reply to comment #5) > Genone, would a KEYWORD="~unsupported", plus p.mask, be practical for you? Why on earth would that be necessary? Stuff in p.mask is unsupported anyway, and if it's so unsupported that not even p.mask is good enough then just don't stick it in the tree. pioto, both me and vapier are in qa@g.o alias, I suppose he (like me) would like to avoid receiving the mails double and triple. I already receive it for qa, alsa-bugs, media-video and pam-bugs for instance. Crypto done: =app-crypt/openssl-tpm-engine-0.3 > Why on earth would that be necessary? Stuff in p.mask is unsupported anyway,
> and if it's so unsupported that not even p.mask is good enough then just don't
> stick it in the tree.
Simple: /etc/portage/package.mask is evaluated before /etc/portage/package.unmask, so if there's a masked (because beta, but mostly working and somewhat supported) version of alsa-driver in the tree, let's call it 1.0.15_beta1, and there's the 9999 version (to avoid me getting 20 bug reports a day when a new vanilla-kernel-2.6.23_rc1 is released - and sorry, but I cannot simply drop it, as users bothering me _do_ stop good things to be done in other parts of the tree) also in package.mask, the users have to know how to properly unmask 1.0.15_betas without unmasking 9999.
As we know our users, we also know half of them will simply unmask all of alsa-driver, ending up using 9999 and expecting it to be supported.
Give me a proper way to get the users to unmask only the 1.0.15_betas and not the 9999, and I'll be sold.
I disagree with the current policy then. -* means 'Remove all previous keywords' Thats all it means. It doesn't need to have 'special meaning for a certain set of packages'. If an app works on x86 and amd64 but no other arches (binary package), pmask it in base/ and unmask it in the arch profiles. You can't have your cake (-* = pmask) and eat it too (-* x86 amd64 is ok for some strange exceptional reason?). After discussing this a bit w/ antarus et all I thought I'd throw out my idea. It seems like the current handling is broken, but at the same time p.masking it also seems brokenish. Wouldn't it make more sense for in the case of "live" ebuilds or alpha snapshots to simply drop keywords all together? -keywords (or -*) seems to be implying "known not to work" whereas that is not true in the case of live ebuilds. Live ebuilds are not known to work. They have not been tested (they really cannot be tested) and as such it seems like it would make more sense to simply unkeyword them. I think this would solve flameeyes issue (requires the user to overlay the -9999 ebuild in order to get it) and also solves the -* issue. Then again I'm sure theres something I'm not thinking about, which at least one of the following commenters will point out. (In reply to comment #10) > I disagree with the current policy then. > > -* means 'Remove all previous keywords' For ACCEPT_KEYWORDS, yes. For KEYWORDS, no, as that variable isn't an incremental and order there doesn't matter. From a portage point of view KEYWORDS="foo -* bar" should be equal to KEYWORDS="foo bar". The only point of having -arch (and by extension -*) in KEYWORDS is to indicate to users/devs that something is known to definitely not work for those keywords. (In reply to comment #11) > Wouldn't it make more sense for in the case of "live" > ebuilds or alpha snapshots to simply drop keywords all together? -keywords (or > -*) seems to be implying "known not to work" whereas that is not true in the > case of live ebuilds. Live ebuilds are not known to work. They have not been > tested (they really cannot be tested) and as such it seems like it would make > more sense to simply unkeyword them. I think this would solve flameeyes issue > (requires the user to overlay the -9999 ebuild in order to get it) and also > solves the -* issue. Then again I'm sure theres something I'm not thinking > about, which at least one of the following commenters will point out. Problem is that you don't have any unmasking facility with that solution, so you pretty much force people to copy those ebuilds to an overlay and add keywords there, with the usual overlay problems attached: Redo it for every version, in case of live-cvs ebuilds regulary check if the tree version has been updated since the last copy, possible shadow effects and so on. That's the only reason why I didn't tell people to do that yet. A possible solution would be to change the meaning of "*" in package.keywords from "all versions with any stable keyword" to "all versions" (disabling the keyword visibility filter completely) or add a new token with that effect. (In reply to comment #12) > A possible solution would be to change the meaning of "*" in package.keywords > from "all versions with any stable keyword" to "all versions" (disabling the > keyword visibility filter completely) or add a new token with that effect. I've heard that paludis is doing this now. I would like to make portage do that too but it has the unfortunate consequence of possibly changing the meaning of people's existing package.keywords files. However, me instinct tells me "*" in package.keywords is uncommon anyway, given it's current definition. How about this as a solution: Update the current and testing versions of portage with a simple addition, make it impossible to have, for example: sys-apps/portage, or >=sys-apps/portage-1.2.3, or <=sys-apps/portage-1.2.3 in package.unmask. Make it so that it is only possible to have ~ and = some definate version in package.unmask. This will solve the issue of users unmasking the live -9999 versions of the ebuild. This is a _very_ simple solution and yet effective. Then you can worry about the semantics of -* after this is done. To be honest, as a user it really does make sense to only allow the unmasking of a specific version because the items are in mask for a reason and to allow the unmasking of all versions is really just quite frankly a terrible idea and can only lead to a mess and harm ... wait ... it did lead to a mess. ;) Please consider this idea. It's logical, and worthwhile to do, and it should be fairly easy to modify the code that checks unmasking to only allow ~ and = operators. ~ just so revisions are unmasked, it won't allow future versions, but I like the idea of allowing revisions, that's at least safer than unmasking everything. Cheers. (In reply to comment #13) > (In reply to comment #12) > > A possible solution would be to change the meaning of "*" in package.keywords > > from "all versions with any stable keyword" to "all versions" (disabling the > > keyword visibility filter completely) or add a new token with that effect. > > I've heard that paludis is doing this now. Only until the tree is fixed. Also note that the use.conf syntax used by Paludis does not correspond to Portage's package.keywords, so it's not a very good comparison. > I would like to make portage do > that too but it has the unfortunate consequence of possibly changing the > meaning of people's existing package.keywords files. However, me instinct > tells me "*" in package.keywords is uncommon anyway, given it's current > definition. * in package.keywords is *very* common. It's the method recommended and used by arch teams for testing a package that hasn't yet had sufficient interest to be keyworded on that arch. (In reply to comment #14) > make it impossible to have, for example: sys-apps/portage, or > >=sys-apps/portage-1.2.3, or <=sys-apps/portage-1.2.3 in package.unmask. Make > it so that it is only possible to have ~ and = some definate version in > package.unmask. This will solve the issue of users unmasking the live -9999 > versions of the ebuild. Ouch, nooo... Please stop bugging me, if I unmask an unversioned atom, I *really* mean it and I really want to unmask any and all masked versions out there, incl. the live VCS ones. If some clueless users do this and get bitten it the ass, that's what they deserve; RTFM before unmasking stuff at least or don't mess with this. mplayer-bin is a binary-only package, only supported on amd64, and as such appears to be correctly using -*. (In reply to comment #16) > (In reply to comment #14) > > make it impossible to have, for example: sys-apps/portage, or > > >=sys-apps/portage-1.2.3, or <=sys-apps/portage-1.2.3 in package.unmask. Make > > it so that it is only possible to have ~ and = some definate version in > > package.unmask. This will solve the issue of users unmasking the live -9999 > > versions of the ebuild. > > Ouch, nooo... Please stop bugging me, if I unmask an unversioned atom, I > *really* mean it and I really want to unmask any and all masked versions out > there, incl. the live VCS ones. > > If some clueless users do this and get bitten it the ass, that's what they > deserve; RTFM before unmasking stuff at least or don't mess with this. > Well, this suggestion was for flameeyes because he mentioned that users are just doing that -- unmasking the live ebuilds and he gets the bug reports about them. So, that's why I suggested it. He wanted a solution that would keep users from unmasking the live ones easily so he could follow the guidelines about the -* in ebuilds. I thought this was a simple solution and yes, I do agree with you for the most part that if a user is stupid enough to unmask a live ebuild, then he/she does deserve the broken system, but then, I try to look at it from the developers point of view and if a slight change like this that is very small and relatively easy to do stops a lot of bug reports, then it's worth it. (In reply to comment #18) > I try to look at it from > the developers point of view and if a slight change like this that is very > small and relatively easy to do stops a lot of bug reports, then it's worth it. Except that those bug reports would be replaced by feature requests to restore the old behavior ;) (In reply to comment #12) > A possible solution would be to change the meaning of "*" in package.keywords > from "all versions with any stable keyword" to "all versions" (disabling the > keyword visibility filter completely) or add a new token with that effect. Added support for a '**' token to be used in package.keywords in r5759 to match any package (even with KEYWORDS=""). Once that is released there is no more reason for abusing KEYWORDS="-*". So would we use KEYWORDS="" instead, then? (In reply to comment #21) > So would we use KEYWORDS="" instead, then? Yes. Thanks genone, that sounds good to me together with p.mask :) (In reply to comment #20) > Added support for a '**' token to be used in package.keywords in r5759 to match > any package (even with KEYWORDS=""). Once that is released there is no more > reason for abusing KEYWORDS="-*". I've included this feature in portage-2.1.2-r3. Somebody please fix repoman :) KEYWORDS.missing 1 media-sound/alsa-driver/alsa-driver-9999.ebuild (In reply to comment #25) > Somebody please fix repoman :) > > KEYWORDS.missing 1 > media-sound/alsa-driver/alsa-driver-9999.ebuild Converted it to a warning. ALSA and Amarok done. Fixed baselayout-lite. Fixed : sci-electronics/magic-7.5.40 sci-electronics/ng-spice-rework-9999 sci-electronics/xcircuit-3.6.59 Denis. gnash fixed, thanks OK now that gnash is "fixed" how do I get the live ebuild to work? I have tried: ACCEPT_KEYWORDS="" emerge -pv gnash and ACCEPT_KEYWORDS="-" emerge -pv gnash with the following result: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] net-www/gnash-0.7.2 [0.7.2_p20099999] USE="nsplugin -agg -ffmpeg -gstreamer -kde -xml" VIDEO_CARDS="-i810" 0 kB My package.unmash contains: =net-www/gnash-0.7.2_p20099999 Make sure you have >=sys-apps/portage-2.1.2-r3 installed and then do the following: echo "net-www/gnash **" >> /etc/portage/package.keywords Thanks that worked. Fixed: =app-emulation/aranym-0.9.0 Updated list: app-emulation/wine-20050111-r2 herd:wine maintainer: app-emulation/wine-20050211 herd:wine maintainer: app-emulation/wine-20050310-r1 herd:wine maintainer: app-emulation/wine-20050419 herd:wine maintainer: app-emulation/wine-20050524 herd:wine maintainer: app-emulation/wine-20050628 herd:wine maintainer: app-emulation/wine-20050725-r1 herd:wine maintainer: app-emulation/wine-20050830 herd:wine maintainer: app-emulation/wine-20050930 herd:wine maintainer: app-emulation/wine-9999 herd:wine maintainer: dev-embedded/bitbake-9999 herd:embedded maintainer: dev-lisp/cl-mel-base-0.5.11 herd:common-lisp maintainer: dev-lisp/cl-mel-base-0.5.20 herd:common-lisp maintainer: dev-lisp/cl-mel-base-0.5.22 herd:common-lisp maintainer: dev-lisp/cl-mel-base-0.5.30 herd:common-lisp maintainer: dev-lisp/cl-rsm-bool-comp-1.0-r1 herd:common-lisp maintainer: dev-lisp/cl-zebu-3.5.5 herd:common-lisp maintainer: dev-util/elfsh-0.65_rc1 herd:hardened maintainer:vapier@gentoo.org dev-util/mingw-runtime-3.10 herd:toolchain maintainer: dev-util/mingw-runtime-3.11 herd:toolchain maintainer: dev-util/mingw-runtime-3.11_p20061202 herd:toolchain maintainer: games-fps/quake3-9999 herd:games maintainer: games-fps/qudos-9999 herd:games maintainer: gnustep-apps/stshell-0.10.0 herd:gnustep maintainer: gnustep-apps/stshell-0.9.1 herd:gnustep maintainer: gnustep-libs/steptalk-0.10.0 herd:gnustep maintainer: gnustep-libs/steptalk-0.9.1 herd:gnustep maintainer: media-video/freej-0.8.1 herd:video maintainer:media-video@gentoo.org net-wireless/orinoco-9999 herd:mobile maintainer:steev@gentoo.org sys-apps/initng-9999 herd:base-system maintainer: sys-apps/sandbox-1.2.18 herd:no-herd maintainer:sandbox@gentoo.org sys-apps/tcng-9h herd:no-herd maintainer:robbat2@gentoo.org sys-auth/pam_krb5-2.2.6 herd:pam maintainer:pam-bugs@gentoo.org sys-boot/grub-1.95 herd:base-system maintainer: sys-devel/binutils-2.17.50.0.10 herd:toolchain maintainer: sys-devel/binutils-2.17.50.0.11 herd:toolchain maintainer: sys-devel/binutils-2.17.50.0.13 herd:toolchain maintainer: sys-devel/binutils-2.17.50.0.14 herd:toolchain maintainer: sys-devel/binutils-2.17.50.0.15 herd:toolchain maintainer: sys-devel/binutils-2.17.50.0.9 herd:toolchain maintainer: sys-devel/gcc-3.2.2 herd:toolchain maintainer: sys-devel/gcc-config-1.4.0 herd:toolchain maintainer: x11-base/xorg-server-1.2.99.0 herd:x11 maintainer: x11-drivers/xf86-input-keyboard-1.2.0 herd:x11 maintainer: x11-libs/libast-9999 herd:no-herd maintainer:vapier@gentoo.org x11-terms/eterm-9999 herd:no-herd maintainer:vapier@gentoo.org x11-wm/enlightenment-0.16.9999 herd:no-herd maintainer:vapier@gentoo.org I have fixed everything from the list, thanks. following up on this old bug is the issue that many live ebuilds in the tree still use KEYWORDS="~x86 ..." Here is a list: ./dev-libs/xqilla/xqilla-9999.ebuild ./x11-wm/fluxbox/fluxbox-9999.ebuild ./x11-wm/enlightenment/enlightenment-0.16.9999.ebuild ./dev-db/ctdb/ctdb-9999.ebuild ./app-text/scrollkeeper/scrollkeeper-9999.ebuild ./app-i18n/skk-jisyo/skk-jisyo-9999.ebuild ./sys-devel/sparse/sparse-9999.ebuild ./sys-devel/gnuconfig/gnuconfig-99999999.ebuild ./app-portage/gatt/gatt-9999.ebuild ./media-tv/xbmc/xbmc-9999.ebuild ./app-admin/eselect/eselect-9999.ebuild ./app-arch/xz-utils/xz-utils-9999.ebuild ./games-mud/wxmud/wxmud-9999.ebuild ./app-doc/repodoc/repodoc-9999.ebuild ./app-doc/pms/pms-99999999.ebuild ./app-pda/libopensync-plugin-irmc/libopensync-plugin-irmc-9999.ebuild ./app-pda/libopensync-plugin-syncml/libopensync-plugin-syncml-9999.ebuild ./app-pda/libopensync-plugin-google-calendar/libopensync-plugin-google-calendar-9999.ebuild ./app-pda/libopensync-plugin-python/libopensync-plugin-python-9999.ebuild ./app-pda/libopensync-plugin-kdepim/libopensync-plugin-kdepim-9999.ebuild ./app-pda/libopensync-plugin-gnokii/libopensync-plugin-gnokii-9999.ebuild ./app-pda/libsyncml/libsyncml-9999.ebuild ./app-pda/libopensync-plugin-palm/libopensync-plugin-palm-9999.ebuild ./app-pda/msynctool/msynctool-9999.ebuild ./app-pda/libopensync/libopensync-9999.ebuild ./app-pda/libopensync-plugin-file/libopensync-plugin-file-9999.ebuild ./app-pda/libopensync-plugin-vformat/libopensync-plugin-vformat-9999.ebuild ./app-pda/libopensync-plugin-gpe/libopensync-plugin-gpe-9999.ebuild ./app-pda/libopensync-plugin-evolution2/libopensync-plugin-evolution2-9999.ebuild ./app-emacs/ngnus/ngnus-9999.ebuild ./app-emacs/gentoo-syntax/gentoo-syntax-9999.ebuild ./dev-python/django/django-9999.ebuild ./games-rpg/mangos/mangos-9999.ebuild ./sys-fs/yaffs-utils/yaffs-utils-9999.ebuild ./sys-fs/btrfs-progs/btrfs-progs-9999.ebuild ./sys-fs/yaffs2-utils/yaffs2-utils-9999.ebuild ./sys-fs/btrfs/btrfs-9999.ebuild ./sys-fs/zfs-fuse/zfs-fuse-9999.ebuild ./net-im/sim/sim-9999.ebuild ./sys-apps/initng/initng-9999.ebuild ./local/layman/pd-overlay/media-sound/pd-devel/pd-devel-0.41.4.9999.ebuild ./local/layman/pd-overlay/media-sound/pd-devel/pd-devel-0.39.0.9999.ebuild ./local/layman/pd-overlay/media-plugins/ggee/ggee-9999.ebuild ./local/layman/pd-overlay/media-plugins/freeverb/freeverb-9999.ebuild ./local/layman/pd-overlay/media-plugins/creb/creb-9999.ebuild ./local/layman/pd-overlay/media-plugins/maxlib/maxlib-9999.ebuild ./local/layman/pd-overlay/media-plugins/aalex/aalex-9999.ebuild ./local/layman/pd-overlay/media-plugins/dfx-transverb/dfx-transverb-9999.ebuild ./local/layman/pd-overlay/media-plugins/footils-knob/footils-knob-9999.ebuild ./local/layman/pd-overlay/media-plugins/iem-iemgui/iem-iemgui-9999.ebuild ./local/layman/pd-overlay/media-plugins/bbogart-popup/bbogart-popup-9999.ebuild ./local/layman/pd-overlay/media-plugins/footils-shabby/footils-shabby-9999.ebuild ./local/layman/pd-overlay/media-plugins/grh-adaptive/grh-adaptive-9999.ebuild ./local/layman/pd-overlay/media-plugins/pdmtl/pdmtl-9999.ebuild ./local/layman/pd-overlay/media-plugins/pmpd/pmpd-9999.ebuild ./local/layman/pd-overlay/media-plugins/frankenstein/frankenstein-9999.ebuild ./local/layman/pd-overlay/media-plugins/dfx-buffer_override/dfx-buffer_override-9999.ebuild ./local/layman/pd-overlay/media-plugins/k_cext/k_cext-9999.ebuild ./local/layman/pd-overlay/media-plugins/k_guile/k_guile-9999.ebuild ./local/layman/pd-overlay/media-plugins/iem-iem_tab/iem-iem_tab-9999.ebuild ./local/layman/pd-overlay/media-plugins/footils-fluid/footils-fluid-9999.ebuild ./local/layman/pd-overlay/media-plugins/dfx-polarizer/dfx-polarizer-9999.ebuild ./local/layman/pd-overlay/media-plugins/moocow-pdstring/moocow-pdstring-9999.ebuild ./local/layman/pd-overlay/media-plugins/tkwidgets/tkwidgets-9999.ebuild ./local/layman/pd-overlay/media-plugins/dfx-library/dfx-library-9999.ebuild ./local/layman/pd-overlay/media-plugins/folderpanel/folderpanel-9999.ebuild ./local/layman/pd-overlay/media-plugins/mrpeach-osc/mrpeach-osc-9999.ebuild ./local/layman/pd-overlay/media-plugins/arraysize/arraysize-9999.ebuild ./local/layman/pd-overlay/media-plugins/grh-GApop/grh-GApop-9999.ebuild ./local/layman/pd-overlay/media-plugins/iem-iemguts/iem-iemguts-9999.ebuild ./local/layman/pd-overlay/media-plugins/getdollarzero/getdollarzero-9999.ebuild ./local/layman/pd-overlay/media-plugins/purepd/purepd-9999.ebuild ./local/layman/pd-overlay/media-plugins/mjlib/mjlib-9999.ebuild ./local/layman/pd-overlay/media-plugins/beatpipe/beatpipe-9999.ebuild ./local/layman/pd-overlay/media-plugins/pdogg/pdogg-9999.ebuild ./local/layman/pd-overlay/media-plugins/dfx-skidder/dfx-skidder-9999.ebuild ./local/layman/pd-overlay/media-plugins/ffext-tracker/ffext-tracker-9999.ebuild ./local/layman/pd-overlay/media-plugins/OSCx/OSCx-9999.ebuild ./local/layman/pd-overlay/media-plugins/footils-syncgrain/footils-syncgrain-9999.ebuild ./local/layman/pd-overlay/media-plugins/iem-comport/iem-comport-9999.ebuild ./local/layman/pd-overlay/media-plugins/ffext-notemono/ffext-notemono-9999.ebuild ./local/layman/pd-overlay/media-plugins/mapping/mapping-9999.ebuild ./local/layman/pd-overlay/media-plugins/hcs/hcs-9999.ebuild ./local/layman/pd-overlay/media-plugins/destroysend/destroysend-9999.ebuild ./local/layman/pd-overlay/media-plugins/iem-iemmatrix/iem-iemmatrix-9999.ebuild ./local/layman/pd-overlay/media-plugins/ann/ann-9999.ebuild ./local/layman/pd-overlay/media-plugins/bbogart-entry/bbogart-entry-9999.ebuild ./local/layman/pd-overlay/media-plugins/miXed/miXed-9999.ebuild ./local/layman/pd-overlay/media-plugins/zexy/zexy-9999.ebuild ./local/layman/pd-overlay/media-plugins/iemlib/iemlib-9999.ebuild ./local/layman/pd-overlay/media-plugins/grh-PDContainer/grh-PDContainer-9999.ebuild Hope this helps... EBo -- |
