Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Sat, Nov 08, 2003 at 11:28:50PM +0100, Robert Millan wrote:
> > 3. You seem to have a problem with the kernel-source-* packges,
> > which I honestly don't follow.
>
> Do you understand what standarisation means?
Is that your problem? Having source distributed in binary packages?
Then please tell me what your problem with kernel-package is, because
that's even better than your solution: with kernel-package there's not
even need for distributing _yet another_ copy of the same sources.
Since you are still avoiding my question regarding your userbase, I
don't know if you care about distributing binary images or not. From
your initial email (the one before the ITP) I got the impression you
cared more about the packaging method than anything else (and that's
still my impression), which doesn't make that much sense to me, unless
you can show that your method has an advantage and still produces the
same results. In the absence of that, you are duplicating work for the
fun of it.
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.
> > >> I could finaly work out where everything is, but the current
> > >> situation is confusing.
> >
> > 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?
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.
> > And that's a problem... why? I don't mean to say that the
> > situation is perfect nor beautiful, but please do tell me how you
> > want to fix that. [...]
>
> I thought it was easy to understand. My package basicaly does:
>
> - Merge kernel-{image,source,patch} in one package (orig+diff+deb)
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)
> - Merge different versions in a single one (the latest)
This has been beaten to death. You have:
* 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.
* A package which requires a reboot on updates
* A package that might break other packages when it's upgraded
(change System.map, don't reboot, and watch stuff stop working)
> - Merge sub-architectures (except, perhaps, in very special cases)
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.
> You're wasting my time by arguing this. I'll rather respond to it by
> showing you a multi-arch package.
I'll have a sit while waiting, I hope you don't mind.
> > Do notice that this asseveration implicitly expands your userbase
> > to non-i386 users, which in my book fall flat out of the category
> > "newbie".
>
> Not in mine, but note there's a difference between targetting at
> newbies and targetting at people who want a more consistent scheme.
I know plenty of people who don't use i386's, and _one_ of them _could_
be called a newbie, but I can't say that with a straight face.
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. Or could it be that your target
userbase won't be using your binaries but only your source packages?
In which case, why do you want to waste autobuilder time providing
binaries? (and, apropos, you could make this easier to understand if
you bother to answer my question regarding your target userbase)
> Yep. They have to do a dummy source upload so that buildd's rebuild
> it with no changes.
Come again? Oh, right, you build-depend on kernel-patch-debian, your
packages won't see the security patches until they hit that package.
You didn't mean to say that, did you? 'cuz the security team is very
bitchy regarding having packages with known security problems in the
distribution, specially when there's already a DSA covering it.
> On the other side, end users of non-i386 get the update inmediately.
Of supported non-i386.
> > just wondering, since you asked who "everybody" was)
>
> The security team is not everybody, so my question still remains.
ftp-master, but that shouldn't be a concern, the port maintainers, QA
people, among others. But that's the same list you have every time you
add a package to the distribution, which isn't a problem in general,
but is when the new package is something that we _already_ have. Oh
yeah, Debian users out there fielding questions such as "why did my
sound card stopped working the day after the last apt-get update?" Ok,
maybe not everybody on the planet, but some significant amount of
people. Happier?
> > That bug is not prevented by your scheme. People using your
> > packaging won't see it,
>
> Yep, and that's an advantage.
Yep.
> > but that's one or two universes away from what you claim.
>
> What did you think I claim, exactly?
Which part of "preventing the bug" don't you get? Unless, of course,
you intend to replace kernel-image-* or _do something_ about that, too.
> I don't see why should I do that. Enumerating the advantages is quite
> enough. Some people will appreciate them, and some not.
You are duplicating effort by providing something that already exists.
I think it's more than justified to ask you who you think your users
are.
> Herbert said what he said, period. Wether my package is suitable for
> stable or not is behind the scope of his mail.
Oh, then keep your packages in p.d.o/~rmh/whatever please. Because
that's Debian hosting them. Which is what Herbert said, nothing more,
nothing less.
--
Marcelo
Reply to: