The dev manual says new virtuals should be discussed on -dev BEFORE being added to the tree: http://devmanual.gentoo.org/general-concepts/virtuals/index.html In this case, I believe the discussion is very important.
There has been a lot of discussion on irc today about these new virtuals. With the addition of virtual/libudev and virtual/libgudev, there are now 4 virtuals for pulling in udev. The existing virtual/dev-manager and virtual/udev follow the standard GLEP 37 style of virtuals. Each virtual is simply a pointer to a different provider of either dev-manager (mdev etc) or udev (eudev, systemd, etc) The new virtuals, on the other hand, represent a completely new way to use virtuals. In this case, each virtual is pointing to the same package, but the subslot is different to allow for proper subslot rebuilds only when needed. eg: If a package links to libgudev but not libudev: Before new virtuals: When libudev changes soname, the package would need to be rebuilt unnessesarily because subslot would change. After new virtuals: Dep is on virtual/libgudev which doesn't change subslot and doesn't need to be rebuilt. Personally, I can see why this is so desirable, but on other bugs, there have been other solutions, and I'm a little terrified to see what happens if every lib which provides multiple libs needs one virtual per lib in case soname changes on what lib but not the rest...
(In reply to Rick Farina (Zero_Chaos) from comment #0) > The dev manual says new virtuals should be discussed on -dev BEFORE being > added to the tree: > > http://devmanual.gentoo.org/general-concepts/virtuals/index.html > > In this case, I believe the discussion is very important. emphasis on the word *should*, no policy was broken here, but I've sent a mail to -announce few mins ago anyway, as I didn't even know there was such an recommendation in place up until yesterday will migrate to the dictionaries when if and when they are introduced to tree, re bug 462138, with that said, don't bother me again, unless something is broken or this valid use of subslots get banned by the PMS
(In reply to Samuli Suominen from comment #2) > (In reply to Rick Farina (Zero_Chaos) from comment #0) > > The dev manual says new virtuals should be discussed on -dev BEFORE being > > added to the tree: > > > > http://devmanual.gentoo.org/general-concepts/virtuals/index.html > > > > In this case, I believe the discussion is very important. > > emphasis on the word *should*, no policy was broken here, but I've sent a > mail to -announce few mins ago anyway, as I didn't even know there was such > an recommendation in place up until yesterday Ignorance is not an excuse here. > > will migrate to the dictionaries when if and when they are introduced to > tree, re bug 462138, with that said, don't bother me again, unless something > is broken or this valid use of subslots get banned by the PMS I think the idea here is that the new style virtual should not hit stable until some discussion has been had on the -dev list. I don't think saying 'we can talk about it when they are stable' is reasonable here. My understanding is that the package.mask was (is) meant to prevent them from hitting stable (either intentionally, or by accident.) Is that a problem? -A
(In reply to Alec Warner from comment #3) > (In reply to Samuli Suominen from comment #2) > > (In reply to Rick Farina (Zero_Chaos) from comment #0) > > > The dev manual says new virtuals should be discussed on -dev BEFORE being > > > added to the tree: > > > > > > http://devmanual.gentoo.org/general-concepts/virtuals/index.html > > > > > > In this case, I believe the discussion is very important. > > > > emphasis on the word *should*, no policy was broken here, but I've sent a > > mail to -announce few mins ago anyway, as I didn't even know there was such > > an recommendation in place up until yesterday > > Ignorance is not an excuse here. Then every second developer is guilty, as you propably know yourself too, this particular guideline is not enforced or widely used. New virtuals are added to tree constantly without sending mails to the ML. However, now that I'm aware of this, I have sent an mail to -dev-announce, and it has been in moderation line for hours now. I don't know what's the hold up, maybe manpower within moderators. > > > > > will migrate to the dictionaries when if and when they are introduced to > > tree, re bug 462138, with that said, don't bother me again, unless something > > is broken or this valid use of subslots get banned by the PMS > > I think the idea here is that the new style virtual should not hit stable > until some discussion has been had on the -dev list. I don't think saying > 'we can talk about it when they are stable' is reasonable here. My > understanding is that the package.mask was (is) meant to prevent them from > hitting stable (either intentionally, or by accident.) > > Is that a problem? > > -A Yes, it (= this bug) is... Virtuals are normal packages, they are not special, that was the whole point of moving away from the profile defined virtuals. Futher, subslots were approved by the council for the EAPI, and making use of them in packages is not forbidden in anyway. And maintainers can stabilize their own virtuals without even opening a bug, since they don't install any files. I expect this to happen after the udev-212-r1 and eudev-1.5.3-r1 stabilization bugs are done. So, meanwhile everyhing is working as expected and no policys have been broken, I really take offense at bothering me with any of this. If at any point, better alternative is given (like bug 462138), we will of course make use of the features just like we are doing now. Or if at any point something becomes broken, we will be sure to fix them asap.
idk if this is the place, but virtual/libgudev has a dependency on systemd[gudev]. Systemd no longer uses the "gudev" USE flag and that's preventing systemd from updating.
You should probabably open a separate bug report for that issue
