While working on a pamless profiles I came across the need for PROVIDES to understand !? ( pkg ) syntax. Here is an example for (shadow) PROVIDE="pam? ( virtual/login )" for (pam-login) PROVIDE="!pam? ( virtual/login )" ---------------------------------- When we try this the virtuals file becomes corrupted and must be hand repaired. hardened db # cat /var/cache/edb/virtuals sys-apps/console-tools sys-apps/kbd pam? sys-apps/shadow virtual/python dev-lang/python virtual/kernel sys-kernel/linux-headers virtual/glibc sys-libs/glibc ) sys-apps/shadow virtual/editor app-editors/nano virtual/bootloader sys-apps/lilo virtual/linux-sources sys-kernel/grsec-sources ( sys-apps/shadow virtual/login sys-apps/shadow virtual/ssh net-misc/openssh virtual/modutils sys-apps/modutils virtual/os-headers sys-kernel/linux-headers ---------------------------------- The idea here is we have two packages that can both provide the /bin/login depending on USE flags. When -pam is set then we need to ensure that pam-login is tossed out the door and blocked. Ideas, suggestions and workarounds are welcome, otherwise I'd like to see this type of functionaly get added.
again, another arguement for unification of the !?() parsing function for *DEPEND, PROVIDE, and SRC_URI ;)
SpanKY, Could you please point out another bug or two where this functionality was requested/needed if any exist.
dev-portage can somebody please make a comment on this? Yes/No/Go Away anything. It's very discouraging for developers when you don't/won't comment on bugs.
Presently, PROVIDE should only be unversioned cat/pkg atoms with "cat" being "virtual". The need for conditional PROVIDEs is fairly plain, but will require a fair few changes implementation-wise, so it'll take a bit of time. There's no real workaround at the moment that doesn't break the ebuild caching.
I've come across the need for this again and I'm not sure how to proceed. Basically we will need to test for use uclibc in a fair # of packages and then conditionally provide a PROVIDE= This will thrash your cache I assume but without any another option I'm not sure what to do.. I know I sure as heck don't want to hear devs yelling about QA problems when no other solution exists. It would be really really cool if we could get this functionaly of !?() in portage. hint hint smile :)
carpaski requested I mark this as a blocker. Once this is solved the embedded herd can actually start getting to work. Till then I guess we might have to resort to hacks that will end up killing the cache, such as use blah && PROVIDES=
Will be out in the next .51 release. Make sure to do some local testing to ensure that it works properly before it starts being used within the tree.
And don't use it in the tree until .51 is stable for some time (a few weeks at least).
Jason, very very nice. Were you able to code it in such a way that it would be nice to the cache? If not should I/we also add something like RESTRICT=portage-cache to the ebuilds that would use this type of functionality? ---------------------- genone, The reason to not use in it the tree would be to avoid the virtuals corruption as mentioned in comment #0 ? If so then should any ebuild that would benefit from these conditional provides also maybe have a dep of >=sys-apps/portage-2.0.51_pre14 ?
The reason is that you have no control about the users portage version and this new feature looks like it has an effect on depgraph creation (not comletely sure on that), so a simple DEPEND would not suffice. It's the same rule as for any change that affects naming, versioning, parsing or depgraph creation. And the cache should be ok as the same syntax is used for *DEPEND and SRC_URI.
It won't break the cache. That's the main reason I put it in. Along with use-based SLOT support, there should be no reason for dynamic stuff in the global section of ebuilds after .51. It is used in dep graph creation, but that is due to fixing bug 54608. Essentially, the virtuals are updated as the graph is built so that, for example, xorg-x11 -> xterm -> virtual/x11 doesn't install xfree. It should be safe to use as soon as .51 goes stable as long as you put a depend on it. For ~arch ebuilds, it could even be done earlier, but not until .51 is unmasked.
Jason, has this been released?
Bug has been fixed and released in stable portages on or before 2.0.51-r2
the code that handles this is broken USE=-pam emerge shadow -pv Calculating dependencies - !!! Problem in sys-apps/shadow dependencies. !!! 'in <string>' requires string as left operand exceptions shadow ebuild has this: PROVIDE="!pam? ( virtual/login )"
Created attachment 43189 [details, diff] portage-provides.patch It seems to work with this...
*** Bug 69864 has been marked as a duplicate of this bug. ***
The patch is correct. Unfortunately this was the first testing anyone gave it. :/ There was also a similar occurence requiring the use of flatten().
>=portage-2.0.51 will actually support use-based provides. The only catch is that brackets can't be used. So, PROVIDE="use? ( virtual/pkg )" will fail where PROVIDE="use? virtual/pkg" will work without issue.
I should have clarified that last statement.. It applied to the available versions at the time of writing. All versions available in rsync fully support this brackets et al.
