Dale: you're the libc maintainer - are you following this discussion ?
The fundamental problem here is that Manoj wants kernel-headers-* for
development of weirdo programs which require particular kernel headers
to compile.
I don't think this is something that many people will need - after
all, t
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Manoj Srivastava writes ("Re: PW#5-16: Use of /usr/src"): ...
>> Umm, no. The kernel-* package maintainers use kernel-package, which
>> produces (and has produced, in the past) the packages
Manoj Srivastava writes ("Re: PW#5-16: Use of /usr/src"):
...
> Umm, no. The kernel-* package maintainers use kernel-package,
> which produces (and has produced, in the past) the packages
> kernel-{headers,source,doc,image}-. There is no interaction
> required b
Hi,
>>"James" == James Troup <[EMAIL PROTECTED]> writes:
James> Manoj Srivastava <[EMAIL PROTECTED]> writes:
James> Umm, well as the maintainer of kernel-*m68k*, I've already had
James> to interact with the libc6 maintainer.
Yes. But the current method removes one point of
synchronizati
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Umm, no. The kernel-* package maintainers use kernel-package, which
> produces (and has produced, in the past) the packages
> kernel-{headers,source,doc,image}-. There is no interaction
> required between the two sets of maintainers (libc-dev and kern
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Manoj (SuperCite undone): [ Ian: ]
>> > The package that the libc depends on (libc-kernelheaders perhaps)
>> should be a plain .deb file which installs in
>> /usr/include/{asm,...}. The libc should specify the version number
>> via a depe
On Mon, Mar 16, 1998 at 01:58:17PM +, Ian Jackson wrote:
>
> This is still true if instead of kernel-headers-2.0.34 (2.0.34-1)
> installing in /usr/src we have kernel-headers (2.0.34-1) installing in
> /usr/include.
Yes! I would love that idea! I have never liked those
symbolic link
Manoj (SuperCite undone):
[ Ian: ]
> > The package that the libc depends on (libc-kernelheaders perhaps)
> > should be a plain .deb file which installs in
> > /usr/include/{asm,...}. The libc should specify the version
> > number via a dependency, rather than by changing the package
> > name, becau
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> I have a compromise proposal that I think will satisfy the needs
Ian> of both the `keep the kernel sources out of .deb files' and the
Ian> `we must distribute kernel source' people.
[proposal deleted]
Ok. I can do that, if so de
I have a compromise proposal that I think will satisfy the needs of
both the `keep the kernel sources out of .deb files' and the `we must
distribute kernel source' people.
The real problem with kernel sources as .deb's is that there is
insufficient flexibility within dpkg for dealing with issues t
I propose that perhaps source code distributed in .deb packages, such
as kernel sources, be unpacked directly inside "/usr/src", and that
the "/usr/src/debian" directory be designated for opening
.dsc/.orig.tar.gz/tar.gz/diff.gz source sets. It occurs to me that
this would be more of a conven
Ian Jackson <[EMAIL PROTECTED]> wrote:
> Furthermore, noone has yet to my knowledge come up with a good
> argument as to why we should distribute source code in .deb files,
> when we have a much better scheme for source code.
The reason for doing this is in those cases where people who under norma
On Mon, Feb 02, 1998 at 01:59:00PM +, Ian Jackson wrote:
>
> Furthermore, noone has yet to my knowledge come up with a good
> argument as to why we should distribute source code in .deb files,
Ahem, I date to say I did.
Nothing related to kernel or source compiling, it's source code added in
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> 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 fo
Manoj (Supercite undone):
> Christian Schwarz:
> > IMHO, /usr/local/src is the place for the sysadmin,
> > /usr/src is the place for packages.
>
> Not only is this a standard that we supposedly follow, it is
> also existing practice, as demonstrated by the kernel-* packages and
> pcmcia-
Red Hat has a "/usr/src/redhat" directory. Perhaps we should follow
suit, and create a "/usr/src/debian" directory?
I've begun using CVS to maintain my packages. I keep them in
"/usr/src/debian/{Work,Build}".
> However, both FSSTND and FHS are very clearly state:
>
> /usr/src :
>
> [...]
>
> Any non-local source code should be placed in this subdirectory.
>
> IMHO, /usr/local/src is the place for the sysadmin, /usr/src is the place
> for packages.
Agreed.
Hi,
>>"Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:
Christian> However, both FSSTND and FHS are very clearly state:
Christian> /usr/src :
Christian> Any non-local source code should be placed in this
Christian> subdirectory.
Christian> IMHO, /usr/local/src is the place for the sysa
[This mail is part of Debian Policy Weekly issue #5]
Topic 16: Use of /usr/src
STATE: DISCUSSION
There was a discussion on the use of /usr/src on debian-devel a few days
ago. A few people wanted /usr/src to be available for the local system
administrator only, which means that no package may to
19 matches
Mail list logo
