Re: SDK patches and people/daniel (was: Re: Source only uploads?)
On Thu, Oct 30, 2003 at 11:04:25PM +1100, Daniel Stone wrote:
> On Thu, Oct 30, 2003 at 01:30:40PM +0100, Sven Luther wrote:
> > On Wed, Oct 29, 2003 at 01:41:53PM -0500, Branden Robinson wrote:
> > > On Wed, Oct 29, 2003 at 09:18:56AM +0100, Sven Luther wrote:
> > > > If i go ahead, and send you a patch against 0pre1v4, will you apply it ?
> > >
> > > You should know better than to ask for this sort of commitment. I will
> > > do my best to look it over, but I will not promise to apply a patch
> > > sight unseen. That would be a stupid policy and a betrayal of my
> > > efforts to release high-quality packages.
> >
> > I understand, but really this is a very orthogonal issue to the rest of
> > the packages. The actual patch is already commited in the 4.3.0 upstream
> > branch, and was posted on debian-x (where i am taking this discussion
> > BTW) almost 6 month ago if i remember well, and is also in Daniel's
> > tree. It just adds a bunch of :
> >
> > InstallDriverSDKNonExecFile(renderproto.h,$(DRIVERSDKINCLUDEDIR))
> >
> > in the Imakefiles which were previously missing, and the
> > InstallDriverSDKNonExecFile macro only gets called during the make
> > install.sdk target. This may be conflict with other Imakefile
> > modifications patches, but only on the patch application level, not on
> > actual functionality. And as said, it is already in the 4.3.0 bugfix
> > branch upstream, which you claim to have synced to in a previous
> > changelog entry, if i remember correctly.
>
> Everything you've said here is correct: $(MAKE) install.sdk, should just do what
> we need, at this juncture. I also had a tree containing this stuff at
> people/daniel/sdk - I can't remember whether I merged the debian/control stuff
> or not.
>
> Sven, I apologise for this - I've dropped the ball, and forgot to let you know.
No problem, i have not actively pursued it too, but Branden's "work
instead of posting on debian-devel" post brought me back to it.
> Unfortunately, I have way more study to do than time, and am starting to fall
> asleep in the middle of the day. I'm sorry for leaving you in the lurcH.
No problem. It would have been easier if the original patch would have
been added to the main tree though, it is nothing more than was commited
to the upstream 4.3.0 bugfix branch anyway.
> > Well, upstream installs it in /usr/X11R6/lib/Server or something such,
> > and the real use of this package is only to build driver packages with
> > patches applied or driver packages from CVS or third party driver
> > sources. I plan to do such a package nextly, altough i don't know if it
> > will be in time for the sarge release, but this is not important.
> >
> > It is thus analog to the foo-source packages, that are used for kernel
> > modules, or even to the kernel-source package, that is used by the
> > kernel-patch-xxx-<port> to build port kernel-images too, so i think it
> > should do ok.
> >
> > The user/driver packages just unpacks the tarball,
> > patches/copies/modifies the driver sources, and launches compilation.
> > This should provide a nice xfree86-drivers package, which will
> > divert/whatever the xfree86 drivers and install cleanly.
> >
> > I have not yet gone to the practical consideration of that, either i
> > provide the debian directory in the xfree86-sdk packages directly, or in
> > the separate package. Maybe i will do it in the separate package for
> > now, and merge it back later one once we have more experience in it.
> >
> > The alternative is naturally to keep everything in
> > /usr/X11R6/lib/Server, but this will be messy once you build/clean it
> > multiple times, and you need root privilege anyway, and if you just copy
> > the stuff, you may as well tarball it.
>
> I think there's a small misunderstanding: apparently you need a clean copy of
> the tree every time you build a new driver.
Well, maybe not, but this would be easier. You unpack it, build your
stuff, and simply erase it in the clean target. That is what the
kernel-patch-<version>-<port> do at least. Having it in
/usr/X11R6/lib/Server to build and use inplace could also be an idea, i
think the proprietary ati driver folk like doing this, but i don't like
it very much to be used in debian.
Friendly,
Sven Luther
Reply to: