Re: Source only uploads?

[Sven Luther <sven.luther@wanadoo.fr>]

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:
> > That said, i have submited all that is needed for the SDK patch
> > upstream, i have sent a patch back then, the only thing missing is the
> > needed work to actually build it, and even then, i posted something to
> > the list a few weeks ago.
> 
> Okay.
> 
> > 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.

> > This will include the stuff i already commited to the upstream 4.3.0
> > bugfix branch, and doesn't in any way influence stuff not related to
> > the SDK (it is just a bunch of SDK related Imakefile fixes). The
> > second part is the needed modification to build a xfree86-driver-sdk
> > package containing a single tarball of the SDK to be unpacked wherever
> > you want.
> 
> Debian packages that just ship tarballs to be "unpacked wherever you
> want" seem pretty nasty to me.  If the best distribution format for
> something is a .tar.gz, then I don't see why we should ship it as a
> .deb instead.  Nevertheless I will attempt to discern whether that's
> really the best approach in this particular case.

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 have not seen you make a single comment on this subject, and my
> > patches went unanswered, beside of your mention that Daniel is working
> > on them. 
> 
> DanielS seemed to care about the issue, so I delegated it to him.  Why
> should I micromanage something I have delegated?  Is it your impression
> that he has lost interest?  If so, then the task needs to be reassigned.
> 
> He did make a commit the other day that I don't fully understand yet,
> telling people to "look for stuff in the attic".

Mmm, i will have a look at it, but it is easy to miss these in the huge
volume of debian-x. especially since the log messages don't fit in the
upper part of my mutt screen, i should diminish the amount of headers
though.

> > And you believe in making things more difficult for the DD, so as to
> > separate the elite from the rest, or maybe those that have paid debian
> > jobs from the others ?
> 
> I expect people who want me to do something to do a little better than
> issuing a list of demands.  The vast majority of my work on XFree86 is
> unpaid volunteer time, so I really don't know what you hope to achieve
> by casting vague asperions about "paid Debian jobs" and "elites".

Well, you are discriminating the quality of the debian developer by the
amount of time they can pass on reading mailing list. You and me clearly
can do a lot of reading, but this is not the case for everyone, and
there is no true reason for making it hard on them on purpose.

> If there's an "elite" in Debian, I'm pretty sure I'm not a member of it.

Yes you are.

Friendly,

Sven Luther