Severity 384282 serious
thanks
Well, we discussed this issue a bit on #debian-x irc channel (log appended)
and it seems that indeed this is probably a bug, and the libgl1-mesa-dri
provides of libgl1-mesa-glx should be droped before the etch release.
Upping the severity accordyingly, in agreement with Steve Langasek, as noted
below.
Friendly,
Sven Luther
21:49 < svenl> hi.
21:50 < svenl> i just did an upgrade to 7.0, and noticed that even
xlibmesa-dri is there, and in the description says it pulls in libgl-mesa-dri,
it doesn't do this in reality.
21:54 < shawn_work> i thought xlibmesa-dri was a meta package for libgl-mesa-dri
22:01 < svenl> shawn_work: it should pull it in anyway.
22:04 < vorlon> Package: xlibmesa-dri
22:04 < vorlon> Depends: libgl1-mesa-dri
22:13 < svenl> vorlon: sure.
22:13 < svenl> vorlon: that is also what i saw, but i had the xlibmesa-dri
package, but not the libgl1-mesa-dri package.
22:13 < svenl> vorlon: an upgrade from may or so, will investigate tomorrow,
need to go to offlineland.
23:37 < svenl> vorlon: also, i got that by investigating another user's
problem who was suffering from the same problem.
23:38 < vorlon> I don't see how a package's deps not being satisfied is an X
problem...
23:40 < vorlon> Reverse Provides:
23:40 < vorlon> libgl1-mesa-glx 6.4.2-1.1
Day changed to 23 aoû 2006
08:33 < svenl> vorlon: well, the problem of the dep being provided, while it
should pull in the new mesa packages.
08:34 < svenl> vorlon: as such, it is a x problem, since the transitory
package is supposed to do just that.
08:36 < vorlon> how do you come to that conclusion? I don't see anything in
the package description that tells me it's supposed to pull in libgl1-mesa-dri
as a real package. If it's wrong for the dep to be satisfied
by libgl1-mesa-glx, I think that's a bug in libgl1-mesa-glx's provides.
08:37 < vorlon> indeed, a quick look at the description of libgl1-mesa-glx
leaves me pretty sure of this
09:10 < svenl> hi vorlon
09:11 < svenl> vorlon: i come to that conclusion, because after an upgrade,
xlibmesa-dri was installed, and its description states libgl1-mesa-dri was
supposed to be pulled in, but libgl1-mesa-dri was not there.
09:11 < svenl> vorlon: notice that i mention the -dri thingy.
09:11 < svenl> not the -glx one.
09:13 < svenl> xlibmesa-dri depends on libgl1-mesa-dri, and if the upgrade
left the system with xlibmesa-dri, but no libgl1-mesa-dri, there is something
obviously wrong with that upgrade plan.
09:16 < svenl> vorlon: ah, the reason for that is obvious, libgl1-mesa-glx is
the one provideing libgl1-mesa-dri, and thus makes the whole stuff not pull in
the -dri stuff, and thus making direct rendered accelerated 3d
graphics not work.
09:16 < vorlon> I just said that.
09:16 < svenl> vorlon: well, i am not sure, but in the pre-upgrade times, you
had to install the dri hardware drivers, for 3d accell to work.
09:17 < svenl> vorlon: if you had working 3d accell before the upgrade, it
should be expected that this stays so after the upgrade, which is currently
not the case, and thus buggy, no ?
09:18 < svenl> vorlon: i got to this because i had a user reporting the
problem, and i helped him about it yesterday, so i believe that this will be a
major headeache post etch release.
09:18 < vorlon> so file a bug against libgl1-mesa-glx for having wrong
Provides already, FFS.
09:18 < svenl> if that is how it should be, ok.
09:21 * svenl has some trouble understanding the logic behind the
libgl1-mesa-glx description and what it means for DRI. One one hand it says it
can do direct rendering just alone, on the other side, it says to install
libgl1-mesa-dri for hardware rendering, and provides the libgl1-mesa-dri which
makes sure it is never pulled in by dependency.
09:35 < svenl> vorlon: ok, bug report filled. Not sure if i was clear enough.
09:43 < svenl> vorlon: Bug#384282
09:44 < vorlon> svenl: cheers
09:54 < MrCooper> svenl: -glx is libGL, -dri is the DRI drivers
09:55 < MrCooper> I don't understand why the former would provide the latter,
you'd have to ask Marcelo I guess, but he seems MIA again
insane? Because I can't remember a time when it made any sense to me.
09:56 < svenl> MrCooper: indeed, thus my surprise.
09:57 < svenl> MrCooper: especially as the xlibsmesa-dri package is installed,
and used to take care of that if i remember well.
09:58 < MrCooper> svenl: xlibmesa-dri is just the old name for libgl1-mesa-dri
09:58 < svenl> MrCooper: indeed.
09:58 < svenl> MrCooper: which is why i was so suprised by the dri support
suddenly vanishing.
09:59 < svenl> MrCooper: is there any reason you would want not to install
libgl1-mesa-dri ?
09:59 < MrCooper> svenl: sure, if you can't use the DRI but want to use
indirect GLX
10:00 < svenl> MrCooper: well, you would use libgl1-mesa-glx then, not ? or
are both mutually exclusive ?
10:00 < MrCooper> svenl: err yes, that's the point, only -glx but not -dri
10:01 < MrCooper> svenl: I agree the provides is probably a bug, but maybe
we're missing some subtle reason for it
10:02 < svenl> MrCooper: err, but would it then not make sense to disable it
in a configuration file, instead of removing the package ?
10:02 < svenl> MrCooper: i believe the right thing would be to provide libgl1,
and not libgl1-mesa-dri.
10:02 < MrCooper> svenl: apples and oranges
10:02 < vorlon> and probably some wormy cherries
10:03 < MrCooper> svenl: of course, as it does already
10:03 < svenl> MrCooper: well, the thing is that you can do hardware detection
in scripts to handle config files, while dependencies are global per arch.
10:03 < svenl> MrCooper: indeed, sorry.
10:04 < svenl> MrCooper: we should just drop the -dri provides.
10:04 < MrCooper> svenl: if you can't use the DRI drivers, you might want to
save the disk space
10:04 < MrCooper> svenl: think thin client
10:04 < svenl> MrCooper: my guess is that this provides is part of the
replace/conflict with older libgl1-mesa, but since provides cannot be
versioned.
10:05 < svenl> MrCooper: if you have disk space problems, there are load of
stuff you would like to remove first.
10:05 < MrCooper> whatever; putting them in the same package as libGL doesn't
make sense to me
10:05 < vorlon> MrCooper: of course you might want to have -glx without -dri.
That's not a reason to pretend that -glx is identical to -dri for dependency
purposes.
10:06 < MrCooper> vorlon: yeah, I thought we agreed that's a bug...
10:06 < svenl> MrCooper: the reality is that you have to weight the need of
the users wanting DRI, and not being able to get i out of the box either on
new
installs or on upgrades, with those who want to save space.
10:06 < vorlon> then what are we talking about?
10:06 < MrCooper> vorlon: no bloody clue :}
10:07 < MrCooper> svenl: -dri is recommended, so (module this bogus provides)
it should get installed by default
10:07 < MrCooper> s/module/modulo/
10:07 < svenl> Maybe one solution would be to reverse the order of the xorg
dependencies, putting libgl1-mesa-dri before libgl1-mesa-glx, which would
(maybe) make apt install libgl1-mesa-dri be considered before the -glx
one, and thus the real package should take precedence.
10:07 < vorlon> it won't get installed by default when the package declares
that it satisfies its own recommends
10:07 < svenl> MrCooper: where is -dri recomended ? It is a depends of the
xorg meta-package.
10:08 < MrCooper> vorlon: hence the modulo
10:08 < svenl> vorlon: it should come in from xorg i believe.
10:08 < svenl> MrCooper: and no, it is not a recomends, but a dep.
10:09 < svenl> vorlon: if marcelo doesn't show up before the etch release, who
is supposed to fix this ? Should we mark it as RC in order to not forget it or
something ?
10:09 < MrCooper> hmm, I thought -glx recommended at some point, but maybe my
memory is failing me
10:09 < MrCooper> or maybe the Provides: was supposed to be Recommends:?
10:09 < vorlon> svenl: I would mark it as serious, yes.
10:09 < MrCooper> I certainly think it should recommend it
10:09 < svenl> vorlon: will you severity up the bug, or can i do it mentioning
you approve ?
10:09 < vorlon> svenl: please do so, I'm in the middle of a few other things
at the moment
10:10 < svenl> maybe post the irc log, expurging the derogatory comments
against marcelo ?
10:15 < MrCooper> hmm, mesa-pkg-devel svn doesn't seem to have the Provides:,
digging in XSF svn...
