[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xlibmesa naming and relationships



Hi Michel,

 thanks for the Cc: ...

>> Michel Dänzer <daenzer@debian.org> writes:

 > > I still don't get it. There's no incompatibility between
 > > xlibmesa3-gl, xlibmesa4-gl and xlibmesa5-gl to come, so what's the
 > > point of the different names? The worst thing IMHO is
 > > x-window-system-core depending on one particular of these, but I
 > > think it would be much easier for everyone if we had a common name
 > > which reflects the libGL API used.

 Don't look at me.  The "3" in the mesa packages makes me puke.  It's
 old historical baggage (you probably know why it's there in the first
 place -- but don't ask me why the xlibmesa packages have that ugly 3 or
 4 or whatever in them).  As you are well aware of, changing a package's
 name in Debian is next to impossilbe.  Provides isn't enough because
 versioned provides don't exist, and that's because everytime the topic
 is discussed, people amuse themselves with corner cases.  The reasoning
 is that if a feature exists and it can be used in technically wrong
 ways, it *will* *be* used in those ways.  And I better stop here before
 I start ranting about Debian's organization at large.

 > Also, what's with changing the semantics of the libgl1 virtual
 > package?  Shouldn't a new one like libgl1-noglu be introduced?

 Before replying I took a look at debian-x's archives (which I haven't
 read, for, what? A year and a half? I lost tack).  I see there was some
 ill-advice involved in all of this.

 Recap: the reason why *I* split the GLU bits out of the mesa packages
 is because all the mesa packages were duplicating the functionality
 (that is, each and every mesa package provide libGL and libGLU).  I'd
 like to make it possible to install multiple mesa packages at the same
 time, mostly because I expect to provide ES packages in the future (I
 got to get myself a Radeon before that happens[0]) and that's just
 easier if I have a separate GLU package.  The other reason was to have
 a GLU package that the nvidia packages can depend on.  I *hate* the way
 the current packages work (depending on the xlibmesa packages just to
 divert their libGL files out of the way).

 I made some mistake with the Provides, Depends, Conflicts, Replaces in
 the original split (I forget what exactly, it's fixed now).  Now I see
 that instead of pointing it out, people pushed Branden to follow suit.
 Now that he did I don't really have a problem with it (well, none
 besides the fact that libglu1-mesa and xlibmesa3-glu are the *exact*
 *same* library[1]).  

 The end-effect is that:

    * Packages can depend on libGLU if they actually use it.  Probably
      moot as Qt depends on libGLU which means you install krap[2] and
      you get libGLU thrown in for free.

    * The nvidia packages can depend on libGLU as they should have done
      from the very start.  Shouldn't care, it's non-free anyways...

    * I don't ship the exact same library with three different packages
      (bitwise exact... as in cp libGLU.so.1 debian/mesa*/usr/lib --
      don't nitpick please, you know what I mean)

    * I can play silly games with alternatives and stuff when the time
      comes...

    * People can install the x-bearing packages if that makes them
      happier (which is apparently the case for lots of people -- don't
      know why, don't care)

 Marcelo

 [0] The reason why I don't own a Radeon atm is the sorry state of Linux
     drivers.  No, TNL isn't enough.  If I get myself a radeon, I'd like
     to be able to use fragment programs.  I won't pay EUR 400 for a
     card if I can only use 30% of its functionality.  The DRI drivers
     don't support that and the ATI drivers are, well, lacking wrt to
     the DRI ones.  I do intend to roll up my sleeves, but not right
     now.  I regret the large number of people who were and are happy to
     chew on the bone NVIDIA threw...  myself shamefully included.

 [1] I don't actually have a problem with just depending on XFree86's
     libGLU (now that it's been splitted off, that is); it's only that
     Mesa releases faster than XFree86 and *if* someone sometime submits
     fixes to libGLU, they are probably going to show up first in Mesa's
     version and then in XFree86's.

 [2] Sorry, couldn't resist.  Nothing against KDE.  I can't stand it but
     that's irrelevant in the discussion.  Peace :-)

-- 
Marcelo             | - "Outside! What's it like?"  - "Well -- It's sort
mmagallo@debian.org | of big"
                    |         -- (Terry Pratchett, Truckers)



Reply to: