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 :)).
Friendly,
Sven Luther
Reply to: