Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)
On Mon, Nov 03, 2003 at 08:59:30PM -0500, Branden Robinson wrote:
> On Mon, Nov 03, 2003 at 09:35:53AM +0100, Sven Luther wrote:
> > On Sun, Nov 02, 2003 at 06:01:22PM -0500, Branden Robinson wrote:
> > > Why should the DDK be restricted to only some architectures?
> > Because the SDK is 170Mo big, and the resulting tarball is 50Mo big, and
> > since it is bzip2ed, it will take hours to be generated on m68k.
> Maybe bzip2 is not the wisest choice of a compression method, then.
Your call. It is a compromise between compressed tarball size and
> > Don't know if it is a reason to disable it, but i thought having a
> > easy way to disable it temporary would be a good thing, but again, i
> > am not enough familiar with these issues, your call.
> I can think of one good reason not to switch it off for non-i386
Did i say on non-i386 ? I did only speak about some arches. Also, i am
pretty sure that m68k at least will hardly benefit from recompiled
drivers or other new drivers. I may be wrong though.
> I like to test my packages before uploading them, unlike some people.
I do to. The fact of uploading as sources or not has hardly anything to
do with it. In fact, i was again bitten by my 4.3.0 install, i built
lablgl on my system, and now it pulled some OpenGL symbols only present
in the 4.3.0 mesa libs. I think the mesa libs should benefit from having
an API virtual depend or something such.
> > But then, maybe not, i have not looked into this really but from my
> > knowledge of what happens in the make install.sdk, it should be the same
> > on all arches.
> Yeah, if it basically just slices off a big hunk of the source tree
> irrespective of what drivers are getting *built*, then that should be
> I'm not sure what S/390 will do, though.
> Wait, wait, wait. You're saying "make install.sdk should be the same on
> all arches" and yet the unpacked tarball contains shared objects?
> If the tarball ships a compiled object, when did that object get
> I smell conflicting premises.
Well, i was speaking of file list and not of file content. It even ships
a copy of the X server anyway.
> Ahhh. Yes, in that case dh_shlibdeps should be told to leave it alone.
Well, it is a tarball now, so i guess it is not needed anymore.
> > > I'll have to get MANIFEST updates from all the arches and that will slow
> > > this down even more than the wait in NEW, I suspect.
> > Ok. But maybe it won't be necessary.
> /me frowns
> It will if anything's getting compiled, I'll wager.
Ok, you have more experience on this.
> > Well, the driver packages are only supposed to divert the corresponding
> > drivers, so it should be pretty straightforward. But then, if you have
> > any dpkg-divert wisdom to share with me before i go into that ?
> Use --package and --rename.
Ok, i will keep that in mind. I will use this to build my unreleased
wildcat VP driver and see what happens (currently using a selfbuilt X