Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
Robert Millan <zeratul2@wanadoo.es> writes:
> apt-get source kernel-image-* doesn't bring me the real source. Instead, if
> I want the real source I must be root and install a binary package. Do you
> deny that this is confusing?
I don't understand why you must be root, could you elaborate? I am no
expert in Debian kernel packaging, but why not fetch the source of
kernel-image-*, see what kernel-patch-* packages it depends on and get
the source of them and kernel-source-*? It is not what I would do, as
I build my kernels with make-kpkg, but it doesn't seem impossible. To
a new user this will all be confusing, but they should not compile
their own kernels anyway.
> But this is my discussion. If I don't take part in it,
> who will respond to all these bogus arguments some people enjoy sending in?
>
> Rather, this is you and the other trolls who are wasting my time.
Yeah, sure, if 90% of the people disagree with you, they must all be
trolls. Reminds me of that guy on the wrong lane on the highway...
> On Sun, Nov 09, 2003 at 07:47:37PM -0600, Marcelo E. Magallon wrote:
> > Now do go ahead and do tell me that the packaging is "easy to
> > understand". Define "easy" then, because with the information I have
> > at hand the only reasonable interpretation is "easy for Robert Millan
> > to understand".
>
> It's easy for people who are already used to Debian de-facto standards.
> Since I am and you're not [1], that makes a difference. Therefore don't
> expect to understand it.
>
> [1] Your reasoning shows either you're not used to them, or you're plainly
> trolling. I'll assume the first at your convenience.
What makes you think that Marcelo doesn't use Debian standards? Do you
have any evidence or is this just trolling on your side?
> Some people publicly said in this thread they like the package.
Many more stated the opposite opinion, but I guess you see them all as
trolls.
> Herbert said he likes it at least as an experiment. I got other
> private mails from well-known developers who like my proposal and
> pity your trolling attempts.
Yeah, anonymous sources, and what does "well-known" mean? The cabal?
People who hold an opinion on this and don't weigh in publicly can't
be accounted for. (The exception being the ftpmasters who can just
reject your package on upload...)
> But the real results are shown through Popularity Contest [1] when my package
> reaches unstable. So keep your arguments on this for later.
>
> [1] http://people.debian.org/~apenwarr//popcon/
Since when do we package everything and then see if it makes the
popularity contest? In my opinion you are adding to archive bloat and
this package should not hit unstable. Once it is there, it will take
ages until it gets removed. Why not upload to experimental or such and
if Herbert really likes it, then at some point it can replace the
current kernel packages. I still see a lot of substantial problems, in
particular the removal of the old kernel on upgrade. I never remove an
old kernel before I have thoroughly tested the new one. Last example
where this was necessary was the vanilla 2.4.22 which leads to hard
lock-ups after suspend from sleep on this iBook. Not unusable but
pretty annoying, and always good to have an older kernel to boot into
handy.
> I haven't even thought of my scheme as "becoming the preferred way of
> distributing Debian Linux". So I'll ignore your bogus hipothesis.
So you want to add to the archive bloat? Just to have the Linux kernel
as a "standard" Debian package? So should we all start repackaging our
favorite applications where the maintainer packaging or default
configuration or compiler options are not to our taste? I hope you
would not want that, but I see your package doing exactly that for the
kernel.
> But certainly, you must be very scared of that possiblity, since you're
> wasting your time and inventing bogus arguments just to prevent it from even
> being in Debian at all.
Why is that wasting time? It is called quality assurance, first of all
trying to keep non-needed stuff out of the archive, second (at least
in my opinion) to make sure the maintainers understand their
packages. (For the record, I consider your repeated statement that
Herbert is the real maintainer and you are only the packaging monkey a
quite lame excuse. I don't want Debian maintainers to be just
repackagers, not for upstream, not for another maintainer.)
> How is deinstalling a known-to-be working {libc,bash,coreutils} not an issue?
libc and coreutils are an issue, less so bash. However, for the kernel
there is a good mechanism to keep backup kernels and choose them in a
bootloader. This is a feature, in my opinion, and that this doesn't
work for other packages is no excuse to stop it from working for the
kernel.
> And as I've seen in some other message, quoting kernel-package generated
> postinst, the current packages _do_ suffer of the same problem.
Only if you update a new Debian revision of the same kernel
version. Furthermore, you can always tweak EXTRAVERSION to make the
name unique.
> You know, I could have RTFMed inmediately and respond I know what System.map
> is, but I don't see why this insignificant argument should actualy waste my
> time in reading docs for the only purpose of proving I can read docs.
You are making it worse with every post. So you think reading docs for
your own packages is wasting time? Nice.
OK, the rest of your message is more ignorance and arrogance, I will
stop it here. Do you actually know what the project expects of its
package maintainers? You seem to have a rather shallow understanding
of all the issues involved with kernel packaging, and I strongly
object to this package being uploaded to sid. Experimental would be
fine with me for people to test it.
Lukas
Reply to: