Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 10:32:11AM -0500, Lukas Geyer wrote:
> 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-*?
Yes, but that's even more confusing.
> 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.
It would be confusing to anyone who isn't experienced with it. Making it a
standard Debian package makes it easy to be understood for developers who
are not familiar with that.
> > 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...
Again, I haven't said that. But I won't discuss over this.
> > > 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?
A package that adheres to Debian de-facto standards is easy to understand for
people who are used to Debian de-facto standards.
Marcelo pretends my package, which adheres to Debian de-facto standards, is
not easy to understand.
Therefore, his reasoning shows he's either not used to them, or plainly
trolling.
> > 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.
I don't. But you're abusing my references to trolling.
> > 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.
That's right. Btw, you cut-off the line above in the same paragraph:
"Some people publicly said in this thread they like the package."
> 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.
As I said before, I don't mind uploading to experimental is there's a
consensus on that.
As for the updating issue, I just sent an explanation on how I can deal with
that in response to Colin (but the mail is not archived yet).
> 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.
I have the maintainer's consentment, so it makes sense to me.
> 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.)
When one of your bugs is caused by a Build-Dependency on another package,
does that make you responsible of fixing the other package? I don't think
so, although you might as well help on it.
Well, my package Build-Depends on kernel-patch-debian-*. I'm responsible for
making it work assuming the patchset is correct.
> > 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.
It's not an essential feature, although as I said before (see reference to
mail to Colin, above in this mail) it can be provided without much problem.
> > 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.
Yep, that's right.
Btw, this gives me the idea that EXTRAVERSION could be tweaked to include the
Debian revision for my package, too.
> > 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.
No, I think "reading docs for the only purpose of proving I can read docs"
is wasting my time.
> 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.
As said before, I agree in uploading to experimental is there's a consensus
on that. Then I'll be able to prove my package works properly instead of
spending hours in endless discussion.
--
Robert Millan
"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."
-- J.R.R.T, Ainulindale (Silmarillion)
Reply to: