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

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

>  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

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


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:


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