Re: / -> /usr symlink
> It sounds strange, but I will already get problems with the needed changes
> for Hurd support without such conflicts. It may sound strange, but for some
> developers, porters seem to be second class citiziens. I am a bit afraid
> that Hurd people will be considered third class citizens, if we try too
> strongly to move Linux in direction of the Hurd.
I don't think there is any need for there to be conflict or great apprehension.
We have no desire to make life harder for anyone in the Debian project.
> For example, I am already getting snipping comments about the fact that I
> submitted a bug report with patches to add better cross compilation support.
> (#31795), and this although the patches are completely backward compatible,
> and cross compilation is very reliable on the Hurd (in fact, what we do can
> hardly be called cross compilation).
Well, I won't try to comment on specific details I don't know about. But
I'm sure there is a way these issues can be raised that will not be
offensive to at least the majority of the debian community. Broadening the
technical flexibility of debian and its tools should certainly not be a
generically inflammatory issue!
One can naturally understand many developers' trepidation at making any
fundamental changes to things that work. I see no need for we debian-hurd
folks to press in any way for such changes to be rolled in to a mainline
debian package in the short term if its maintainer's conservatism balks at
the prospect. It should not be difficult to have simple hurd-specific
diffs to apply to mainline packages to produce the hurd packages for these
cases.
Likewise, I would not press including changes in the mainline debian tools
if people in the debian community are uncomfortable with it. We can
continue to make separate patched packages available to be used for
debian-hurd and to demonstrate our ideas about changing the tools or
package structures. This experimentation and engineering in the interests
of generalized future utility, and of practical use for debian-hurd, need
not be a contentious thing. We don't attempt to impose it on anyone; we
offer it as solutions we have tried for problems we have encountered.
If debian is the open and well-spirited community I believe it to be, then
I'm sure that discussions about ideas for future changes in debian and its
tools, and experimental implementations of those ideas, will not be
offensive to the community!
The hurd team and the debian-hurd volunteers are certainly more than open
to discussion and other views on these issues. I think Gordon has been
diligently deferential and noninflammatory hitherto and will be very open
to all voices in the debian community responding to the ideas he wants to
represent. Myself, I don't have the time or the inclination (or probably
the temperament) to figure out a lot of these issues about debian-hurd, and
while I have occasional opinions to offer, mostly choose to defer to the
consensus of the other volunteers to hash these things out.
I don't think any of us want to press against resistance to have changes in
tools or packages, or changes in debian policy, made before the next major
revision, or force our decisions on anyone. We are just floating ideas for
the future, and discussing the problems we are encountering and the ones we
foresee.
Reply to: