Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Sat, Nov 08, 2003 at 07:18:17PM -0600, Marcelo E. Magallon wrote:
> >
> > 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.
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.
> 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.
> > > 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)."
> 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.
> > 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)
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.
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.
As I said before, if I have to add more patches they would go into
debian/patches. Do you understand why my scheme excludes a set of 70
packages that contain a single patch each?
> * 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.
> * 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.
> * 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.
> > - 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.
I don't target at these users. They should use the current packages instead.
> 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.
> Or could it be that your target
> userbase won't be using your binaries but only your source packages?
No, as I said before I want it to work like the rest of Debian.
> 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?
> > 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.
That can be easily handled. First provide a fixed kernel-patch-debian, then
update both current packages simulteneously
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.
> > > 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,
It's just one more package for the ftp-master, not a set of 136 packages
which all need override updates.
> the port maintainers,
In what way could my package break for an architecture and the current ones
not break, if they use the same upstream source with the same patchset?
> QA
> people,
Ditto for QA stuff.
> among others.
Which 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.
We don't have the Linux kernel as a standard Debian package.
> 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?
Just like it happens in the rest of Debian, specialy if you run unstable.
> > 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.
Don't put words in my mouth.
Now read it again, and find my exact quote:
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html
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.
> > 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.
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.
> 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
> > 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.
No. It will go to unstable. Then pass through the standard process we have
in Debian to determine wether a package is suitable for stable or not.
Or did you think I pretend to insert my package into stable directly?
--
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: