Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Sun, Nov 09, 2003 at 07:47:37PM -0600, Marcelo E. Magallon wrote:
> On Sun, Nov 09, 2003 at 02:40:11PM +0100, Robert Millan wrote:
>
> > The packaging method is the whole point. And indeed, some people like
> > the ability to do standard things like "apt-get source foo" and get
> > foo's sources.
>
> Since you like playing word games... what else do you get when you do
> apt-get source kernel-image-2.4.22-1-k7 if not
> kernel-image-2.4.22-1-k7's source package?
>
> Do you want the Linux Kernel sources with all the patches as used by
> kernel-image-* _already_ applied and available in a well known
> location? apt-get install kernel-tree-x.y.z.
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?
> > > an alternative. Having a gazillion variations of a theme might be
> > > a good software developing methodology, but I've got news for you:
> > > Debian is a distribution.
> >
> > You just messed up. Debian is "The Universal Operating System". At
> > least, we claim that in the website title.
>
> Look, if you want to waste time, waste _yours_. OTOH, if you want to
> take part in the discussion, do bother to address the issues you are
> being presented with.
I'd really LOVE to. 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.
> If all you are going to do is nitpick on
> wording, piss off.
You said: "I've got news for you: Debian is a distribution."
Who started the nitpick wording?
> Again, your complain is that there are too many kernel-foo packages,
Don't put words in my mouth. I said the current package set is confusing,
which it is.
> but you are adding more. How does that improve on the problem you
> perceive?
In what way the presence of 136 separate kernel-* packages affects the
confusability of my pair of linux-* ones?
> I was addressing this:
>
> - Easy understanding of the package. Developers looking at the
> package will find every piece in the place Debian packages
> normaly put it. The binaries are in .deb, pristine upstream
> sources are in .orig.tar.gz, the debian/ dir is in .diff.gz
>
> I could finaly work out where everything is, but the current
> situation is confusing. [...]
>
> and keeping in mind that you have a problem with the current way the
> kernel is packaged, I have to conclude that you think that using CDBS
> is a better choice, because if it isn't you wouldn't be using it in the
> first place.
No, I could do the same with plain dh-make'ed templates. It'd have the
advantage that I wouldn't have to discuss silly arguments with you.
But your arguments are not that relevant, so I'll stick with CDBS.
> Futhermore, you argue that the packaging is confusing and
> non-standard. I take you think that CDBS is somehow standard and easy
> to understand. It's neither. After apt-get source foo, foo-x.y still
> _does not_ contain the sources used to build the package. You have to
> take extra steps to do that.
dpkg-buildpackage
> And since there are a couple of these
> hacks floating around, how to get the unpacked patched source is
> non-obvious.
It's as easy as in the rest of packages in Debian, no more, no less: Read
debian/rules.
> 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.
> Debian provides a _distribution_. In this context less is more. We
> have a gazillion emacs (to pick a random example) packages because
> there are _users_ for these packages who _do_ require the different
> versions. This is not about "survival of the fittest", this is about
> satisfying users' needs.
Some people publicly said in this thread they like the package. 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.
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/
> My objection is based on the fact that you are packaging something that
> we _already_ provide,
I responded to this before. We don't provide the Linux kernel packaged as a
standard Debian package.
> without adding any significant value for users
> and along the way creating more problems (you still haven't addressed
> the question of how you satisfy the reboot requirement on upgrades,
> among others).
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00638.html
> Up to this point, the only reason you have provided for
> this new packaging is satisfaying some anal-retentive need of yours
> regarding the source package organization.
Don't you feel ashamed of liing so blatantly? I provided _three_ reasons:
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html
Wether they satisfy anal-retentive needs or not, I don't have arguments
for that topic.
> > First, there's a total sum of 136 packages, from which kernel-patch-*
> > are 70 of them. From these 70, only kernel-patch-debian-* and a pair
> > of architecture-specific patches fit in my scheme.
>
> So you are not going to significantly reduce the number of
> kernel-patch-* packages, which means you don't solve _that_ part of the
> problem you perceive, doesn't it?
Exactly. Instead, I provide an alternative which doesn't suffer from the
same problem.
But I explain this below, so I don't understand why you're asking again.
> > All of these packages are already existing and I don't plan to
> > replace them. Again, you're mixing the question on wether I'll
> > provide 70 linux-patch-* packages (which I won't), and wether I'm
> > going to rely on them.
>
> I am not. Your scarce wording leads me to think you consider the
> number of kernel-patch-* packages a problem.
It's only a problem if you have to use it.
> Let's have a look at the number of kernel-(image|source) packages for
> i386, and let's just assume that your scheme succeeds and becomes the
> preferred way of distributing Debian kernels, what would we have? The
> following:
I haven't even thought of my scheme as "becoming the preferred way of
distributing Debian Linux". So I'll ignore your bogus hipothesis.
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.
> > > * Automatic _deinstallation_ of a working kernel (upgrade from
> > > linux-2.4 2.4.22-1 to linux-2.4 2.4.23-1 and you deinstall 2.4.22)
> > > which anyone who's done system administration for longer than two
> > > minutes is going to tell you is a _very bad_ idea.
> >
> > That's not an issue. I can even backup the stuff in preinst.
>
> You mean to have gone thru all the work of putting this stuff under
> package management just to put yourself in a position where you have to
> do the management by hand? That's clever.
I don't have to. But I can do it as an extra feature as long it doesn't add
more binary packages (which is what I pretend to avoid).
> And do explain it to me please: how is deinstalling a
> known-to-be-working kernel not an issue? How do you guarantee that the
> new kernel image is even going to boot on _any_ machine where the old
> kernel image did?
How is deinstalling a known-to-be working {libc,bash,coreutils} not an issue?
How do you guarantee that the new system is even going to boot on _any_
machine where the old system did?
> > Oh, now I'm suposed to fix that, too? Bitch upstream for a run-time
> > updatable Linux kernel.
>
> ROTFL
>
> That's not the point, I thought that was obvious, sorry. The point is
> how do you guarantee that this reboot is going to happen?
Jamie already responded:
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00638.html
And as I've seen in some other message, quoting kernel-package generated
postinst, the current packages _do_ suffer of the same problem.
> > Actualy, I didn't even bother to provide System.map, and my system
> > works quite well. I can add it if you bring me a reason to do so,
> > though.
>
> That one was already addressed by other people. But that was just an
> example, you ignored the issue itself, which means you haven't thought
> about it.
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.
> What about the fact that modules in /lib/modules/x.y.z are
> gone because you just upgraded to x.y.z+1 but the _running_ kernel is
> still x.y.z?
Reboot.
> Nautilus suddenly can't read a CD because isofs is gone.
> I want to see Takuo deal with that bug report...
Now it is my fault if users send bug reports to the wrong package?
You seem to be particularly good at finding problems to pretend they're
all my fault. What comes next? World hunger?
> > I don't target at these users. They should use the current packages
> > instead.
>
> Ah, thanks, at least a partial answer to my question. See? It didn't
> hurt.
I noticed it partialy answers your question, but it was unintentional.
> If you want your kernels automatically upgraded, fine, your problem.
> But don't inflict that on the rest of Debian. You _can_ have that
> right now, in a less risky way.
Less risky? That's interesting. If you have some suggestions, perhaps you
can help me improve my package.
> > > In which case, why do you want to waste autobuilder time providing
> > > binaries?
> >
> > Because we're Debian. It'd be different if we were Gentoo, wouldn't it?
>
> (just a footnote: you ignored "in which case", but you already knew
> that)
I apologise as it wasn't intentional. Please bring a link (as I always do)
and I'll re-read your question.
> > It's clear the packages taken by autobuilders hit the archive before
> > the ones compiled manualy. If that doesn't happen then we have an
> > infrastructure problem.
>
> I'm not sure what you are trying to say. AFAIU there's a special queue
> in the autobuilders for security related stuff and packages autobuilded
> that way aren't automatically uploaded to the archive (whatever the
> girl is called doesn't like packages without source, and the security
> team doesn't like publishing security fixes before the cat's out of the
> bag, so AFAIUI all this is handled manually)
Do you understand what "infrastructure problem" means?
> > Just like it happens in the rest of Debian, specialy if you run
> > unstable.
>
> Uhm... no. Unstable is a special situation where we _advertise_ that
> it _will_ break at any time. But stable is something else. Systems
> running stable should not break on updates. You can't prevent it but
> you should try to.
When my package hits sid, send me an RC bug. Thanks.
> > And then tell me what you think "us" means in that phrase. I
> > apologise if it sounds ambigous, but you can still deduct it from the
> > context.
>
> "us", Debian, the bug could have happened on any Debian system. The
> fact that a subset of installed systems won't be seeing it, doesn't
> mean it can't happen (i.e., that it can be prevented). You can't
> express a dependency on a particular kernel version with dpkg, can you?
"us" means "all existing systems that use this method".
"[...] would enforce updating on all existing systems that use this method.
This prevents us from [...]"
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html
> > Yes. And you're not entitled to tell me when I shouldn't duplicate
> > someone else's effort. I do it because it's worthy of doing.
>
> And you are welcome to do whatever you want in your $HOME. I'm not
> telling you what you can and can't do with your time. But placing the
> package in the distribution is a different thing, there you _are_
> duplicating effort.
I recall you failed to justify why this duplication of effort is significant
in <[🔎] 20031109011817.GA20572@racsa.co.cr>, so don't bring it up again.
> > > I think it's more than justified to ask you who you think your
> > > users are.
> >
> > Sure. My users are those who like the advantages described in:
> >
> > http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html
>
> Sure, you are free to keep quoting that URL as often as you want
Of course I am. Aren't you asking the same question as often you want?
> (which
> still doesn't answer the question in a satisfactory way),
Of course it does. Tell me what is inconsistent in my list of advantages. (And
please, don't repeat the same arguments over again).
> > Or did you think I pretend to insert my package into stable directly?
>
> Gee, it didn't occur to me that your first upload was going to be to
> unstable or experimental... /like every other maintainer does with
> every other package in this project/.
Indeed.
--
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: