[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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

> > 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: