1. emerge udev results in: [ebuild U ] sys-fs/udev-135-r2 [124-r1] [blocks B ] >=sys-fs/udev-125 (is blocking sys-apps/hal-0.5.11-r1) the hal ebuild version 1.14, Wed Dec 24 15:39:11 2008 UTC has a new restiriction defined: !>=sys-fs/udev-125. this prevents upgrading udev that is needed to support sys-apps/openrc-0.4.1 2. i have another system that already had sys-fs/udev-135-r2 installed proior to the new hal ebuild(1.14), and yet now it has the sys-apps/hal-0.5.11-r1 installed too so it`s in an inconsistent state. Reproducible: Always Steps to Reproduce: 1.have sys-apps/openrc-0.3.0-r1 installed 2.have sys-fs/udev-124-r1 installed 3.have sys-apps/hal-0.5.11-r1 installed 4. emerge udev Actual Results: [ebuild U ] sys-fs/udev-135-r2 [124-r1] [blocks B ] >=sys-fs/udev-125 (is blocking sys-apps/hal-0.5.11-r1) i have udev and sysvinit in the portage.keywords file marked with the ~x86 keyword. emerge --info output: Portage 2.1.4.5 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r7 i686) ================================================================= System uname: 2.6.25-gentoo-r7 i686 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz Timestamp of tree: Wed, 24 Dec 2008 01:45:03 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.5.2-r7 dev-util/cmake: 2.4.6-r1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch webrsync-gpg" GENTOO_MIRRORS="http://gentoo.osuosl.org/ " LANG="he_IL.utf8" LDFLAGS="-Wl,-O1" LINGUAS="en he" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/alon-barlev-portage /usr/local/ase-portage" SYNC="" USE="X aac acl acpi alsa arts berkdb bidi bluetooth branding bzip2 cairo cdr cli cracklib crypt cups cupsddk curl dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox fortran gdbm gif gphoto2 gpm gstreamer gtk hal hdaps iconv ipv6 isdnlog jpeg jpeg2k kde kdeenablefinal kerberos ldap libnotify logrotate mad midi mikmod mmx mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png pppd python qt3 qt3support qt4 quicktime readline reflection samba sdl session spell spl sse sse2 sse3 ssl startup-notification svg svga sysfs tcpd tiff truetype unicode usb vorbis wifi win32codecs x86 xcomposite xinerama xml xorg xulrunner xv zlib" ALSA_CARDS="hda_intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en he" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
why don't you upgrade to hal-0.5.11-r4 then? It seems that you already know to unmask unstable packages, if you need an unstable openrc version, in your system. I resolve the bug as WONTFIX. Reopen if necessary(or if I'm thinking something wrong here)
(In reply to comment #1) > why don't you upgrade to hal-0.5.11-r4 then? It seems that you already know to > unmask unstable packages, if you need an unstable openrc version, in your > system. Hi, I have a similar situation, which is not recommended- openrc-0.4.1 installed (including udev-135-r2), but my hal is 0.5.11-r1, which is not allowed by hal's ebuild. Your suggestion to go unstable in hal as well, increases the instability level of my laptop. This is not something I wish to perform. There has to be a way which will allow people to keep stability (or increase it) rather than going deeper into the twilight zone. Can you move the "!>=sys-fs/udev-125" limitation to the unstable hal ebuild ? Doron.
(In reply to comment #2) > Hi, > I have a similar situation, which is not recommended- > openrc-0.4.1 installed (including udev-135-r2), but my hal is 0.5.11-r1, > which is not allowed by hal's ebuild. Your suggestion to go unstable in > hal as well, increases the instability level of my laptop. This is not > something > I wish to perform. There has to be a way which will allow people to keep > stability (or increase it) rather than going deeper into the twilight zone. > Can you move the "!>=sys-fs/udev-125" limitation to the unstable hal ebuild ? > > Doron. > There are reasons, if something is not recommended. Either use stable or use unstable. Mixing both is at your own risk. And this blocker has a simple reason: people with your hal version complained, because it does not work with unstable udev. So this just prevents you from more problems. Either upgrade hal or downgrade openrc+udev. Else you would get a not working system. What do you prefer? :)
See also bug #251820 . There you can find the reason for that blocker line. (http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/hal/hal-0.5.11-r1.ebuild?r1=1.11&r2=1.12)
(In reply to comment #4) > See also bug #251820 . There you can find the reason for that blocker line. > (http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/hal/hal-0.5.11-r1.ebuild?r1=1.11&r2=1.12) > OK, I see your point. On the other hand, there's no real alternative to go stable on openrc, since all baselayout-2 is unstable. Only option is downhill... I must say this is quite frustrating... Anyway, I accept your response. You may want to drop a link to this issue in the forum, for all those in my state. Also ewarn could be nice, since you're actually causing an inconsistent situation. Thanks, Doron.
(In reply to comment #5) > (In reply to comment #4) > > See also bug #251820 . There you can find the reason for that blocker line. > > (http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/hal/hal-0.5.11-r1.ebuild?r1=1.11&r2=1.12) > > > > OK, I see your point. > On the other hand, there's no real alternative to go stable on openrc, since > all baselayout-2 is unstable. Only option is downhill... I must say this is > quite frustrating... > Anyway, I accept your response. You may want to drop a link to this issue in > the forum, for all those in my state. Also ewarn could be nice, since you're > actually causing an inconsistent situation. > > Thanks, > Doron. > OMG, you 're kidding right? Please, tell me why on earth the unstable hal-0.5.11-r4 will increase the "instability level" of your laptop. See the diff with the -r1 ebuild in http://dev.gentoo.org/~pchrist/temp/hal.diff and the differences between the patchsets http://dev.gentoo.org/~pchrist/temp/hal_patches_1-3_diff.txt . I also have to say, that both ebuilds are for hal 0.5.11. I just can't understand how you actually think. Merry Christmas, anyway :D
(In reply to comment #6) > I also have to > say, that both ebuilds are for hal 0.5.11. I just can't understand how you > actually think. Merry Christmas, anyway :D > The fact that one ebuild is marked unstable and the other not, is enough to make people think twice before they go that lane. After all, as you can see from baselayout to openrc to udev and now hal- every unstable package leads to another one. I'm quite sure that in a short while we'll get something which is hal-related and needs to go unstable, since I'll be using the unstable hal. It not hal-specific just the fact that every unstable package eventually leads to another unstable one (even if it was stable up 'till now). Merry Christmas to you too, and thanks again. Doron
