Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)
On Sun, Nov 02, 2003 at 06:01:22PM -0500, Branden Robinson wrote:
> > > No, I don't have a DONT_BUILD_SERVER option. As I've explained on this
> > > list before, the variables are called NOT_BUILDING_X_SERVER and
> > > NOT_BUILDING_XF86_SERVER, and they are *descriptive*, not
> > > *prescriptive*.
> >
> > Come on, i was writing this mail without the sources before my eyes, but
> > i understand you perfectly understood what i meant, so there is no need
> > for bickering about it.
>
> You don't seem to understand what I mean by "descriptive" versus
> "prescriptive".
>
> > So, do you want to add a NOT_BUILDING_XF86_DDK around the changes ?
>
> Why would I? For what architectures would this be defined?
>
> > Considering the tarball is quite big, and it may take lot of time on
> > slow arches, it may be a good idea.
>
> 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. 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.
> > > > The patch come in two parts, the actual patch sdk.diff, which add the
> > > > needed stuff to debian/rules and debian/control, and the MANIFEST.diff,
> > > > which is the diff for the added SDK files on x86.
> > >
> > > The MANIFEST changes will have to applied to all the MANIFEST files, of
> > > course.
> >
> > I am not sure if we need to apply the same MANIFEST file or not, some of
> > the files may not build on all arches maybe, not sure though.
>
> Ah, yes. So the only way to get this right is to actually run through
> it on each architecture. Bleah.
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.
> > > FYI, SDK stands for "Software Development Kit", but I don't see any
> > > reason to mention it at all in the package description if it's
> > > misleading -- and it looks like it might be.
> >
> > Upstream calls it SDK though, so it would be nice to have it in the
> > descritption so it shows up in apt-cache search or something.
>
> Good idea.
>
> > > Maybe the package should simply be called "xfree86-ddk"? Why propagate
> > > a misnaming further?
> >
> > Tempting, i say let's go for that.
>
> Okay.
>
> > BTW, i am not sure about the -Nxfree86-driver-sdk in both these cases.
> > They were needed before when i had not done a tarball, but i guess we
> > can remove it now.
>
> dh_strip and dh_shlibdeps should both be harmless when run over the
> xfree86-ddk package, whether it ships just an archive or an unpacked
> tree (which contains only source code, headers, and Makefiles) so I see
> no reason to keep this parameter.
Well, i was afraid it would waste time on slower arches, and
dh_shlibdeps barked on the unpacked tarball version. The unpacked
tarball does contain .so objects, so ...
> > > Anyway, thanks for the patch. I still regard this as a post-4.3.0-1
> > > item, which means it will only be applied before 4.3.0-1 if time
> > > permits.
> >
> > Ok, altough as said, it doesn't cost much, and since we add a new
> > package, it will have to go trough the NEW queue.
>
> 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.
> > Anyway, your package your decision, now you have the full patch, and i
> > will start working on getting the necessary stuff to actually use the
> > DDK. My plan is to add the necessary debian directory to the tarball, so
> > that you only need to unpack it and run dpkg-buildpackage on it to
> > generate the proper driver packages, which should install and divert the
> > xfree86 provided packages, a bit like Michel's DRI trunk package do.
>
> Okay. Remind me to give close scrutiny to all usage of dpkg-divert.
> I've learned a lot of neat[1] things about dpkg-divert over the past
> couple of months, and it can be difficult to get right.
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 wisdo to share with me before i go into that ?
> > Then i will need to hack on the CVS head drivers to make sure they build
> > with it, and i guess some of the proprietary driver writter will also be
> > able to generate packages from it, i think in particular that ATI should
> > be able to generate debian packages directly from it. Not NVidia though.
>
> Okay. I don't have a good handle on that sort of thing yet so I'll have
> to leave it up to you.
No problem.
Friendly,
Sven Luther
Reply to: