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

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
compression time.

> > 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
> architectures.

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
> arch-independent.
> 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
> compiled?
> 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
server :)).


Sven Luther

Reply to: