since the ebuild was changed without revbump, several update configurations cause trouble because VDB and tree ebuilds are out of sync * virtual/udev-208-r2:0::gentoo Did not meet virtual/udev[gudev], use existing if same, installing to / from media-gfx/gimp-2.8.10-r1:2::installed Flag 'gudev' enabled Did not meet virtual/udev[static-libs], use existing if same, installing to / from sys-fs/lvm2-2.02.103:0::installed Flag 'static-libs' enabled
this is not only a problem for paludis user, but also portage users who disable dynamic deps. (virtual/udev-208-r2:0/0::gentoo, ebuild scheduled for merge) conflicts with >=virtual/udev-208[gudev] required by (sys-fs/udisks-1.0.5:0/0::gentoo, installed) ^^^^^ >=virtual/udev-147[gudev] required by (net-misc/modemmanager-1.2.0-r1:0/1::__unknown__, installed) ^^^^^ virtual/udev[gudev] required by (gnome-base/gvfs-1.20.2:0/0::__unknown__, installed) ^^^^^ >=virtual/udev-208[gudev] required by (sys-fs/udisks-2.1.3:2/2::gentoo, installed) ^^^^^ virtual/udev[gudev] required by (media-gfx/gimp-2.8.10-r1:2/2::gentoo, installed) ^^^^^ >=virtual/udev-208-r2[gudev,abi_x86_64(-)] required by (media-plugins/gst-plugins-v4l2-0.10.31-r1:0.10/0.10::__unknown__, installed) ^^^^^ sys-fs/eudev:0 (sys-fs/eudev-1.9-r1:0/0::gentoo, ebuild scheduled for merge) conflicts with >=sys-fs/eudev-1.5.3-r1:0/0[abi_x86_64(-),gudev,static-libs] required by (virtual/libgudev-208:0/0::gentoo, installed) ^^^^^^^^^^^ >=sys-fs/eudev-1.3:0/0[abi_x86_64(-),static-libs] required by (virtual/libudev-208:0/1::gentoo, installed)
well, only official package manager matters and you are asking for trouble if you disabled dynamic deps, but since these are only virtuals, it doesn't cost anything to version bump them, might as well bump them +*udev-215 (29 Jul 2014) + + 29 Jul 2014; Samuli Suominen <ssuominen@gentoo.org> +udev-215.ebuild: + New virtual version wrt #518416 for package managers with no proper in-place + dependency handling. and same for virtual/libudev, virtual/libgudev
I thought portage is an official package manager
also, you are not allowed to code against portage you must code against PMS, that's why it's there
against my better judgement, i've bumped the virtuals already, so i'm not sure why you reopened the bug (In reply to Julian Ospald (hasufell) from comment #3) > I thought portage is an official package manager and Portage has dynamic deps enabled by default (In reply to Julian Ospald (hasufell) from comment #4) > you must code against PMS, that's why it's there and?
(In reply to Samuli Suominen from comment #5) > against my better judgement, i've bumped the virtuals already, so i'm not > sure why you reopened the bug > Thanks, I missed that. > (In reply to Julian Ospald (hasufell) from comment #3) > > I thought portage is an official package manager > > and Portage has dynamic deps enabled by default > You should not rely on optional features which are scheduled for removal.
(In reply to Julian Ospald (hasufell) from comment #6) > > (In reply to Julian Ospald (hasufell) from comment #3) > > > I thought portage is an official package manager > > > > and Portage has dynamic deps enabled by default > > > > You should not rely on optional features which are scheduled for removal. I consider passing --dynamic-deps=n equal to eg. --nodeps. The user of such an option, knows what he is doing, and deals with it himself. Where is the announcement for the feature deletion? What's the replacement (to avoid rebuilding when it's unrequired)?
(In reply to Samuli Suominen from comment #7) > (In reply to Julian Ospald (hasufell) from comment #6) > > > (In reply to Julian Ospald (hasufell) from comment #3) > > > > I thought portage is an official package manager > > > > > > and Portage has dynamic deps enabled by default > > > > > > > You should not rely on optional features which are scheduled for removal. > > I consider passing --dynamic-deps=n equal to eg. --nodeps. The user of such > an option, knows what he is doing, and deals with it himself. > > Where is the announcement for the feature deletion? What's the replacement > (to avoid rebuilding when it's unrequired)? The replacement is static dependencies.
hardly :)
(In reply to Samuli Suominen from comment #9) > hardly :) yes :)
