Summary: | automating x11-base/xfree -> virtual/x11 dependencies | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | John Richard Moser <nigelenki> |
Component: | New packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
ebuild_alter.sh : alter ebuilds for x11
414 package world rebuild new ebuild_alter.sh |
Description
John Richard Moser
2004-03-16 10:30:12 UTC
do this with for i in `find /usr/portage/metadata` as well, else it tries to get xfree anyway. Created attachment 27880 [details]
ebuild_alter.sh : alter ebuilds for x11
This is a script I made from the earlier comment. It runs through your
portage tree and portage cache and alters the ebuilds and portage cache to
depend on virtual/x11 instead of *x11-base/xfree*
It works for me fine, but your mileage may vary. Test it on your own box
before submitting anything to the portage tree.
This is not the correct way for us to do it, although it may work fine for you locally. Every altered ebuild needs to be _proven_ to work with all packages supplying the virtual (at this point xfree and xorg-x11 are expected). They can all be assumed to work with xfree and therefore need to be tested on xorg-x11. Therefore, the correct way to close this bug is to get a listing of all ebuilds depending on x11-base/xfree in any way (a grep -rl x11-base/xfree /var/cache/edb/dep seems to work, sort of). If you'd like to collect and sort such a list by category/package-version, it would be quite helpful. It'd be even more helpful to have the associated herds. Created attachment 27905 [details]
414 package world rebuild
This is output from `emerge -euUDpv world`
You can see I've slipped abi-word 2.1.0 in there (but abi depends on
virtual/x11 anyway), dillo 0.8.0, and xchat 2.0.8. I version bumped all of
these myself, which is why they're not in an overlay; it was a quick hackjob.
I also use several overlays. Only a few packages come from these overlays
though; most come from the portage tree. Because the overlay number is
displayed by these, you can clearly see which come from where.
I've also unmasked gnome. The ebuilds do come from the portage tree.
I'll tell you how it works out. Of the 305 ebuilds that my script altered on
my machine, I probably only hit a few that didn't already depend on
virtual/x11; but it's a start, right? If anything breaks, I'll inform you.
My intent was exactly this. The developers can do the same thing I'm doing
here on their own boxes to track down what's what. I'll probably make a quick
hack and give you a new ebuild_alter.sh to spit out which files are altered, so
you can track it better. I should have thought of that earlier, but better
late than never.
Created attachment 27906 [details]
new ebuild_alter.sh
New ebuild_alter.sh script. This one actually spits out all altered files to
~/ebuild_alter.list
This will let you examine what files were altered by the script, and thus,
directly target your efforts for checking them for misses (i.e. why in the heck
does this alter xfree's ebuild?) and for breakage (do things still have proper
dependencies and still merge properly?). Thus, you may go on a case-by-case
basis and see if the script did any damage. Each ebuild that it properly
alters without regression should be commitable (assuming it makes sense;
xfree-specific drivers and such don't make sense with i.e. kdrive).
Sorry, I feel I may have miscommunicated my intentional use of this thing
earlier. Hopefully here I have covered both what my intent was and fixed the
script to be able to properly support that intent. I hope this is useful.
I seem to have misread your previous comments. I get what you're saying now. My aims were wrong. Sorry for wasting your time. it was a lack of understanding of the issue on my part Marking invalid in favor of bug #45610. As a side note, should non-fully-compatible X11's provide virtual/x11? It is my understanding that i.e. x11-base/kdrive does not work with gtk+1.2 apps, but also does not PROVIDE="virtual/x11". I was told that only fully complient x11 builds should supply virtual/x11. Is this a rule? If so, then the comment made in #3, This is not the correct way for us to do it, although it may work fine for you locally. Every altered ebuild needs to be _proven_ to work with all packages supplying the virtual (at this point xfree and xorg-x11 are expected). They can all be assumed to work with xfree and therefore need to be tested on xorg-x11. would be a little backwards; more likely, when a package is found to not work with a certain virtual/x11 supplying package, it should be determined if that package is bugged or if the x11 is noncompliant (bugged), and thus that should be addressed. If the x11 is the problem, it should lose its virtual/x11 until the bug is fixed. Is this a backwards view of things? The virtual/x11 is really for the libraries, not the server, since that's what other programs build against. kdrive doesn't make any sense to have virtual/x11 -- xlibs do. Giving and taking a virtual/x11 all the time would be complete havoc. Nobody would ever have any idea whether their preferred implementation was valid at any given time and would be switching back and forth whenever we found a bug. true. But if it were a "bug" rather than an "unimplimented feature," it's assumed you wouldn't remove the virtual/x11; it's still compliant, although broken. If it were "Does not actually support X window drawing method Foo, and won't for 5 more releases," that'd be something to pull virtual/x11 for. If it was "We broke the x_DrawWindow() function, we'll fix it in our next revision," that'd just be a bug. |