| Summary: | nvidia-drivers and xorg-server-1.4-r1 for legacy nvidia-drivers | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Neil <nshephard> |
| Component: | Current packages | Assignee: | X11 External Driver Maintainers <x11-drivers> |
| Status: | VERIFIED INVALID | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | 2006.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Neil
2007-09-19 10:14:15 UTC
No. It's up to you to properly configure your system. The nvidia-drivers ebuild specifically states that if you have a card that requires legacy drivers you *MUST* add the appropriate mask to your /etc/portage/package.mask. If you had done that then you would still receive the proper block and everything would work as expected. We're not going to disable functionality that works just fine just because people with older cards can't have the same functionality yet. (In reply to comment #1) > No. It's up to you to properly configure your system. The nvidia-drivers ebuild > specifically states that if you have a card that requires legacy drivers you > *MUST* add the appropriate mask to your /etc/portage/package.mask. If you had > done that then you would still receive the proper block and everything would > work as expected. I'm aware of that and had the appropriate mask in place, but I read the ChangeLog for xorg-server and it indicated.... 19 Sep 2007; Donnie Berkholz <dberkholz@gentoo.org>; xorg-server-1.4-r1.ebuild: Restore Nvidia binary driver support with today's release. so unmasked xorg-server-1.4-r1 only to find things weren't quite as I'd expected as the Nvidia binary driver support for xorg-server-1.4-r1 is only for the current and not legacy drivers. > We're not going to disable functionality that works just fine just because > people with older cards can't have the same functionality yet. Fair enough, I just thought that since the legacy drivers aren't masked in anyway that functionality is being broken, so a block would have been approriate. Would it make things easier if there are multiple slots for the nvidia-drivers given the legacy drivers? I realise that slots are designed for major version's to co-exist (which is highly unlikely to ever be the case for nvidia-drivers), but is there any other way of dealing with this? (Apologies for reopening this bug, no idea if this would get read otherwise, feel free to invalidate it again). Complain to nVidia. *** This bug has been marked as a duplicate of bug 190759 *** (In reply to comment #3) > Complain to nVidia. > > > *** This bug has been marked as a duplicate of bug 190759 *** > Is it? The above bug is about using the wrong driver. This is about a problem between certain versions of nvidia-drivers and xorg-server-1.4.r1 being incompatable. I'd suggest that the ChangeLog for xorg-server should really read something like ... 19 Sep 2007; Donnie Berkholz <dberkholz@gentoo.org>; xorg-server-1.4-r1.ebuild: Restore >=x11-drivers/nvidia-drivers-100.14.19 support with today's release. How to deal with this in the ebuild I'm not sure? I've still a lot to learn about writing ebuilds. Would my above suggestion of using slots work in this situation? (I suspect not, but how would one deal with this, without having a separate ebuild for legacy drivers?) Apologies again for reopening this bug, but I felt it was a) inaccurate to mark it as a duplicate as bug 190759 is about failure to mask properly by a user, not about how to resolve incompatabilities between software versions; b) there's no need to complain to nvidia as I originally indicated that a revision of the legacy drivers are in the pipleline; c) I feel that the xorg-server-1.4-r1 ebuild wasn't fully tested given that the legacy drivers aren't marked ~x86 or masked. Again apologies for reopening, but I felt the "Complain to nvidia" and "duplicate thread" was off-handed and inaccurate, and I'd be keen to _learn_ if there is a way of overcoming this problem (viz. slots or something else?). What exactly do you want? Do you want me to pull a driver out of my hat since NVIDIA hasn't made one? You keep ranting about depends. The depends are 100% proper. Only 100.14.19 and higher will work with xorg-server 1.4, sooooo that's what the depend is. So what exactly do you want? When you express yourself clearly, with a work flow of how you want things to work. THEN open the bug. Until then, none of this has made any sense. p.s. If you're argument is going to involve SLOTs then you don't understand how those work. Straight away I can tell you, no solution to nvidia-drivers will involve SLOTs. (In reply to comment #5) > What exactly do you want? > > Do you want me to pull a driver out of my hat since NVIDIA hasn't made one? > No not at all, there's no implication and I never suggested it, I even linked to details that a revised driver is due soon. > You keep ranting about depends. The depends are 100% proper. Only 100.14.19 and > higher will work with xorg-server 1.4, sooooo that's what the depend is. So > what exactly do you want? > > When you express yourself clearly, with a work flow of how you want things to > work. THEN open the bug. Until then, none of this has made any sense. > > p.s. If you're argument is going to involve SLOTs then you don't understand how > those work. Straight away I can tell you, no solution to nvidia-drivers will > involve SLOTs. I don't see this as an argument and I did indicate that I wasn't 100% sure that slots were the way forward, so thank you for confirming that. I did however feel that Jakub Moc was off-hand and wrong to say that this is a duplicate bug flag (there isn't even any mention of xorg-server in the other bug!) as I do understand how to mask packages and had done. Clarity of expression and indeed thinking on any (complex) subject comes with experience. I've read the http://devmanual.gentoo.org/ many times, but still find it hard to follow in places (for the reasons given at the top of the front page) so my understanding and thinking on how one might proceed with resolving problems with ebuilds isn't as clear as yourself and others who have obviously had far more experience and a more in-depth understanding than the resources available to me permit. I've had a little think about it and perhaps this would clarify what I was thinking (please excuse the conversion to algebra).... * Two packages A (nvidia-drivers) and B (xorg-server) with different versions A1, A2, A3, A4 and B1, B2, B3 and B4 respectively. * B4 requires >=A4 or above. * A user has a masked >A3 Current situation on emerge -uDN world -------------------------------------- * Emerge fails as the mask on >A3 blocks B4 Possible solution? ------------------ * Portage looks at user masks, realises that B4 dependency of >=A4 is not met and doesn't attempt to upgrade B4 as the user clearly understands what they are doing as they have purposefully placed the mask on >A3. Possible problems? ------------------ * I do understand that modular xorg is rather large and this may result in a cascade of problems, but if I remember correctly (currently home comp is turned off so I can't check) the only xorg package I masked whilst waiting for A4 (i.e. nvidia-drivers to be updated) was B4 (i.e. xorg-server-1.4) and left emerge -uDN world to update everything else. This was probably the 'wrong' way of doing it and I was lucky that things didn't break drastically, so maybe portage would have to look at the meta-build from which xorg-server is derived (xorg-x11?) and decide that because the user has knowingly masked packages that things shouldn't be updated, rather than simply blocking? * Some other subtlety that I'm not familiar with? Don't know if thats any clearer, but it seems logical to me. Apologies for wasting yours and others time, I shall content myself with waiting for the release of the updated legacy drivers (and start saving for new hardware ;-) (In reply to comment #6) > Possible problems? > ------------------ > > * I do understand that modular xorg is rather large and this may result in a > cascade of problems, but if I remember correctly (currently home comp is turned > off so I can't check) the only xorg package I masked whilst waiting for A4 > (i.e. nvidia-drivers to be updated) was B4 (i.e. xorg-server-1.4) and left > emerge -uDN world to update everything else. This was probably the 'wrong' way > of doing it and I was lucky that things didn't break drastically, so maybe > portage would have to look at the meta-build from which xorg-server is derived > (xorg-x11?) and decide that because the user has knowingly masked packages that > things shouldn't be updated, rather than simply blocking? The above should read "the only xorg package I masked whilst waiting for A3" sorry for the typo. (In reply to comment #6) > (In reply to comment #5) > > You keep ranting about depends. The depends are 100% proper. Only 100.14.19 and > > higher will work with xorg-server 1.4, sooooo that's what the depend is. So > > what exactly do you want? > > > > When you express yourself clearly, with a work flow of how you want things to > > work. THEN open the bug. Until then, none of this has made any sense. > > > > p.s. If you're argument is going to involve SLOTs then you don't understand how > > those work. Straight away I can tell you, no solution to nvidia-drivers will > > involve SLOTs. > > I don't see this as an argument and I did indicate that I wasn't 100% sure that > slots were the way forward, so thank you for confirming that. > > I did however feel that Jakub Moc was off-hand and wrong to say that this is a > duplicate bug flag (there isn't even any mention of xorg-server in the other > bug!) as I do understand how to mask packages and had done. You're chief complaint is that the depend is on 100.14.19 but that doesn't provide a work around for all graphics cards, specifically ones supported only by legacy drivers. The same complaint was made by the person that submitted #190759. Seemed reasonable to mark it as a dup. > > Clarity of expression and indeed thinking on any (complex) subject comes with > experience. I've read the http://devmanual.gentoo.org/ many times, but still > find it hard to follow in places (for the reasons given at the top of the front > page) so my understanding and thinking on how one might proceed with resolving > problems with ebuilds isn't as clear as yourself and others who have obviously > had far more experience and a more in-depth understanding than the resources > available to me permit. > > I've had a little think about it and perhaps this would clarify what I was > thinking (please excuse the conversion to algebra).... > > * Two packages A (nvidia-drivers) and B (xorg-server) with different versions > A1, A2, A3, A4 and B1, B2, B3 and B4 respectively. > > * B4 requires >=A4 or above. > > * A user has a masked >A3 > > Current situation on emerge -uDN world > -------------------------------------- > > * Emerge fails as the mask on >A3 blocks B4 > > Possible solution? > ------------------ > > * Portage looks at user masks, realises that B4 dependency of >=A4 is not met > and doesn't attempt to upgrade B4 as the user clearly understands what they are > doing as they have purposefully placed the mask on >A3. So you're seeking a Portage change now? Yet previously you talked about a ChangeLog change or a depends change. If you want a Portage change, submit it to the Portage guys. The way Portage currently works it tries to upgrade to the highest version of everything, if it can't because of a mask. It gives a block error. There are several bugs complaining about this in other ebuilds, I recommend you do some searching and take a look. Add your comments on to those. > > > Possible problems? > ------------------ > > * I do understand that modular xorg is rather large and this may result in a > cascade of problems, but if I remember correctly (currently home comp is turned > off so I can't check) the only xorg package I masked whilst waiting for A4 > (i.e. nvidia-drivers to be updated) was B4 (i.e. xorg-server-1.4) and left > emerge -uDN world to update everything else. This was probably the 'wrong' way > of doing it and I was lucky that things didn't break drastically, so maybe > portage would have to look at the meta-build from which xorg-server is derived > (xorg-x11?) and decide that because the user has knowingly masked packages that > things shouldn't be updated, rather than simply blocking? Again, these are Portage changes that is still being requested of the nvidia-drivers maintainer. > > * Some other subtlety that I'm not familiar with? > > Don't know if thats any clearer, but it seems logical to me. > > Apologies for wasting yours and others time, I shall content myself with > waiting for the release of the updated legacy drivers (and start saving for new > hardware ;-) > Sincere apologies for the lack of clarity in my original posts and therefore inappropriate wrangling of my problem. I didn't realise that the problem was so deep-rooted in the behaviour of portage. I shall be more judicious in the reporting of "bugs" in the future. Regards slack eh. don't apologize. sorry for abrasive nature of my replies. feel free to post bugs whenever you see there is something that's an issue, just explain your expected behavior clearer. so basically we must buy new hardware. :) more and more packages will break because of this as time goes on. |
