Re: PW#5-16: Use of /usr/src
Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
(supercite redone)
Ian> Manoj (Supercite undone):
Ian> Christian Schwarz:
Christian> IMHO, /usr/local/src is the place for the sysadmin,
Christian> /usr/src is the place for packages.
Manoj> Not only is this a standard that we supposedly follow, it is
Manoj> also existing practice, as demonstrated by the kernel-*
Manoj> packages and pcmcia-modules. Any gratituos change may well
Manoj> break these packages that have (correctly) followed the
Manoj> standards.
Ian> Those packages are used by a minority of users, I think.
How is that relevant? A standard that we conform to does not
need a popularity count for its component parts.
Ian> Users who do much development work are particularly likely not to
Ian> have used them and also to have used /usr/src themselves.
It does not take rocket science to move directories to
/usr/local/src to get conformant again.
Ian> IMO, since it's fairly easy for us to avoid messing these people
Ian> up, we should make a subdirectory in /usr/src as Karl Hegbloom
Ian> suggests.
I disagree. (So far this has been merely statements of
opinion). We should be concentrating on a) fixing (not merely
closing) bugs, and b) trying to get hamm out the door, rather than
inventing logistical challenges for packages that conform to all the
standards that we follow.
Ian> Furthermore, noone has yet to my knowledge come up with a good
Ian> argument as to why we should distribute source code in .deb
Ian> files, when we have a much better scheme for source code.
I can say the same for the other side. I have, indeed, come up
with several arguments (which, apparently, are not good enough;), and
I have seen nothing but advocacy for breaking the file system
standards and personal preferernces against it.
Ian> I won't be held responsible for the braindamage that results when
Ian> dpkg is used to install source code which is then build in situ.
Fine. You apparently have not tried these packages. If we are
loking to place blame, *I* shall take responsibility. The only
``brain-damage'' I have seen is that there are (occasionally)
non-empty directories when one purges/removbes the package (if one
does a make clean prior to removal there is not even that).
Ian> I'd like to see a policy statement that at least discourages
Ian> distribution of source code in .deb's.
And I strongly object to that.
As to the reasons for packaging up kernel sources. I offer:
a) Most users are encouraged to compile their own kernels,
espescially if there are hardware problems (probing for a
non-existent hardware freezes the machine), or to get a faster,
smaller, less error prone kernel configured to the local machine.
Espescially for new users, it makes sense for Debian to package
known good kernel versions, and make them easy to access.
Experienced Linux folk download from the horses mouth, but
novices find being able to use dpkg-ftp or dft to get kernel
sources very comforting. A deb file is justified since there are
mechanisms in place to get .deb files to users as seamlessly as
possible.
Since compiling a kernel is what most Debian users are
exhorted to do, no matter what novices the are in Unix systems,
this separates the kernel image package from the rest of our
packages, where end user compilation is the exception rather than
the rule.
This reason is enough not to discontinue the practice for
purely aesthetic reasons.
b) There have been, and may again be, patches applied and tested by
the kernel image maintainer that add stability/debian specific
features to a kernel, or to backpatch desred deatures from e
newer kernel that by itself is too unstable to get into Debian
(Yes, I think we are about a higher quality distribution). The
deb file is the most efficient way of disseminating these
improvements.
manoj
who is now afraid of mailing the project leader in fear of being
chastized for using the wrong email address
--
"What can you say about a society that says God is dead and Elvis is
alive?" Irv Kupcinet
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: