#include <hallo.h>
* Jamie Wilkinson [Mon, Nov 10 2003, 06:54:22PM]:
> >The fact of the too generic package name was mentioned before within
> >other arguments against your "linux" package. IIRC you prefered not to
> >answer to it but refered to an URL which did not contain the answers.
>
> 'linux' is a perfect name for the package. The tarballs contain that very
> name.
Note that the name is choosen not only to attract the user, but also to
catch that who blindly use "apt-get source linux". The user wouldn't get
the well-known and good kernel-source packages but something which is
under control of Robert. Further, what they would get is not a clean
source but something with debian/ dir inside which would confuse
make-kpkg. I would not mind if he had called it "linux-rmh" or such.
> >> 2) I use the upstream name. If you don't like it, bitch upstream.
> >
> >Sorry, how much did you drink to find an answer like this one? If Linus
> >changes the package name (which is unlikely to happen ;)), I am sure you
> >would rename your ITP to follow him.
>
> Are you implying that you make up names for the software that you package,
> rather than use the name given to it by upstream? I believe you don't.
Ah, that is a good base to start a discussion. Of course it is better to
keep the upstreams name but make exceptions if they are too generic, to
confusing or to offensive (though we did already accept such ones, eg.
"pornview" ;)).
> Given that there's a possibility that Debian will include non-linux kernels
> in the future. In that case, calling the linux kernel package
> 'kernel-image' doesn't give a lot of room for the other kernels to live in.
> Calling the package 'linux' makes it pretty clear which software it is
> packaging.
I would not call any package "linux" or "freebsd", not even in the
source package name. In fact, for a future development of debian-kernel
packaging, I have written something down few days ago.
...
# create debian-kernel mailing list, found a new project called
# debian-kernel alias DK. Keep the project files in a project-internal
# repository unless the stuff is mature enough to see the daylight of Sid,
# post-sarge.
In addition to the others plan on the mentioned Wiki page, we need
following packages:
linux-kernel-setup: setup utility for the Linux kernel packages created
by the debian-kernel project
(s/linux/Hurd/ or *BSD)
linux-initrd-builder: adapted version of initrd-tools; supposed to
work with d-k kernel packages but not limited to them
packages following the following naming strategy:
linix-kernel-source-2.4.XY: basicaly the upstream source
lk-patch-essential-2.4.XY: hot fixes like for security issues,
compiling problems etc.
lk-patch-recommended-2.4.XY: important but optional patches like
initrd-on-cramfs fix <discuss that>,
vesafb-as-module, bigphysarea...
lk-patch-suggested-2.4.XY: sensible patches but not sensible for
everyone: ipsec backports,
dk-meta-linux-2.4.23: meta package with dependencies/conflicts
to keep the *-2.4.XY packages above in sync
The binary kernel packages would not be longer distributed with
auto-installing script and all the modules inside. Instead, they would use
the <linux|...>-kernel-setup utility. No longer one big package, but create:
linux-kernel-$KVERS: meta package with strong dependency on lki-$KVERS and
maybe some modules packages, see below.
linux-kernel-image-$KVERS: the image itself, including System.map, config, etc.
linux-modules-general-$KVERS: all the general modules, including common
componentes like scsi-hd/cd support used by
usb/firewire/... drivers
linux-modules-ide-$KVERS: includes all the low-level ide drivers
linux-modules-scsi-$KVERS: same for scsi
linux-modules-usb-...: ...
linux-modules-firewire-...: ...
linux-modules-multimedia-...: sound drivers, v4l, joystick drivers, etc.
<end-of-brainstorming>
I am open for discussions about that.
MfG,
Eduard.
--
Was die neuen Unwissenden holen müssen:
Siemens-Lufthaken
