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

Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)



[redirecting this debian-x discussion to your bug report]

On Sun, Nov 02, 2003 at 01:14:43PM +0100, Sven Luther wrote:
> On Sat, Nov 01, 2003 at 04:23:10PM -0500, Branden Robinson wrote:
> > On Sat, Nov 01, 2003 at 05:11:26PM +0100, Sven Luther wrote:
> > > Ok, here attached is what i think a final version of the driver sdk.
> > 
> > If it doesn't apply cleanly, it's your ass.  :-P
> 
> If it doesn't apply cleanly, i send a new one. 

You'd better.  :)

> > 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?

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

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

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

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

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

[1] sarcasm

-- 
G. Branden Robinson                |       The only way to get rid of a
Debian GNU/Linux                   |       temptation is to yield to it.
branden@debian.org                 |       -- Oscar Wilde
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature


Reply to: