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.
> > Let me spell this out for you: unless you _replace_
> > kernel-source-* and kernel-image-* and whatnot, you are not
> > solving your perceived problem, you are making it worse. At some
> > point you claimed it's not your intention to replace, but to offer
> > 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. If all you are going to do is nitpick on
wording, piss off.
Again, your complain is that there are too many kernel-foo packages,
but you are adding more. How does that improve on the problem you
perceive?
> > > > Confusing to you. Sounds like a job for a README. Do
> > > > realise that CDBS (or similar hacks) also require familiarity
> > > > with the particular system.
> > >
> > > You're deliberately mixing things that hold no relation.
> >
> > I beg your pardon?
>
> No. Specialy because you cut off the relevant part of my reply:
>
> "The way debian/rules is created differs from package to package all
> over Debian. It's not new that when you read a debian/rules you might
> not be familiar with it (which, btw, is one of the reasons why CDBS
> exists)."
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. 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. And since there are a couple of these
hacks floating around, how to get the unpacked patched source is
non-obvious.
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".
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.
> > You have a problem with the current source packages, and you have
> > said the source packages for kernel-image-* are confusing, haven't
> > you? I don't see how this is unrelated. Now, if you had answered
> > my question, maybe I could understand what you want to achieve,
> > but you haven't.
>
> There's a difference between the whole structure of a package set
> (wether it has 107 components or just a pair of them) and the
> structure of a debian/rules file. You're pretending that using a
> particular style of debian/rules is a reason for objecting an ITP,
> but it's not.
My objection is based on the fact that you are packaging something that
we _already_ provide, 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). 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.
> > Have you _looked_ at the kernel-patch-* packages? The 70 of them?
> > I guess you realize these things aren't compatible with each
> > other? I assume you mean only kernel-patch-debian-*, in which
> > case you improve the situation only marginally (or you are trying
> > to confuse people by bringing the 70 kernel-patch-* packages into
> > the discussion)
>
> 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?
> 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.
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:
kernel-image-2.2.20-reiserfs | remains in some form AFAIUI
kernel-image-2.4-386 | remains (different name, same thing)
kernel-image-2.4-586tsc | gone, I guess
kernel-image-2.4-686 | gone, I guess
kernel-image-2.4-686-smp | gone, I guess
kernel-image-2.4-k6 | gone, I guess
kernel-image-2.4-k7 | gone, I guess
kernel-image-2.4-k7-smp | gone, I guess
kernel-image-2.4.18-bf2.4 | gone
kernel-image-2.4.22-1-386 | gone
kernel-image-2.4.22-1-586tsc | gone
kernel-image-2.4.22-1-686 | gone
kernel-image-2.4.22-1-686-smp | gone
kernel-image-2.4.22-1-k6 | gone
kernel-image-2.4.22-1-k7 | gone
kernel-image-2.4.22-1-k7-smp | gone
kernel-image-2.4.22-speakup | remains, addresses special needs
kernel-image-2.6.0-test7-1-386 | gone
kernel-image-2.6.0-test9-1-386 | remains in some form AFAIUI
kernel-source-2.2.25 | gone
kernel-source-2.4.19 | gone
kernel-source-2.4.19-hppa | gone
kernel-source-2.4.20 | gone
kernel-source-2.4.21 | gone
kernel-source-2.4.22 | gone
kernel-source-2.6.0-test7 | gone
kernel-source-2.6.0-test9 | gone
That certainly looks good. You just got rid of a bunch of very large
packages, that I grant you. But since people _seem_ to want to have
this architectural flavors, the "I guess" ones aren't really gone. And
I still don't see how the "confusion" has been reduced so dramatically.
I don't see the kernel-image-x.y.z-flavor packages being gone as a good
thing.
> > * 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.
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?
> > * A package which requires a reboot on updates
>
> 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?
> > * A package that might break other packages when it's upgraded
> > (change System.map, don't reboot, and watch stuff stop working)
>
> 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. 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? Nautilus suddenly can't read a CD because isofs is gone.
I want to see Takuo deal with that bug report...
> > So you want to nuke the -386 and -586 and -k7 and whatnot
> > packages? I couldn't care less, I don't use any of those, but I
> > guess there are some users who appreciate them.
>
> 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.
> > But do tell me then, you are not targeting newbies, are you?
> > Because if you don't target them, I don't know what kind of user
> > will want automatic upgrades of the kernel.
>
> Like, say, me. If you call me a newbie at this point we can finish
> the discussion.
What? Is "newbie" an insult now or something like that?
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.
> > 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)
> 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)
> 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.
> 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?
> 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 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 (which
still doesn't answer the question in a satisfactory way), but that
doesn't change the fact that the objection to your ITP still stands.
> 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/.
--
Marcelo
