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

Bug#219582: ITP: linux -- Linux 2.4 kernel



On Mon, Nov 10, 2003 at 02:23:52PM +0000, Colin Watson wrote:
> On Mon, Nov 10, 2003 at 12:03:38PM +0100, Robert Millan wrote:
> > On Sun, Nov 09, 2003 at 08:33:00PM +0000, Matthew Garrett wrote:
> > > klogd will be unable to look up symbols, and ps and top need it for
> > > wchan to be displayable.
> > 
> > I'm so scared. wchan won't be displayable!
> 
> As a prospective maintainer of an important package, it ill behooves you
> to make fun of legitimate bug reports.

No, you're confused. I don't blame you because you probably missed where
the whole System.map discussion came from.

As I just told to Matthew, someone claimed that my package has a dessign
problem in the way it deals with System.map upgrades. But it actualy resulted
that it's just a bug that prevents wchan from being displayable. I can fix
that bug without much trouble.

I'm not making fun of bug reports. Rather, I laugh at people who pretend I'm
incompetent because my package has a trivial bug, or who pretend the dessign
of my package is broken in a way that I can't solve such trivial bugs.

> In particular, klogd not being
> able to look up symbols means that you and upstream will get less useful
> bug reports when the kernel oopses.

Thanks Colin, at last someone cared to give me positive feedback.

I'll fix the System.map issue.

> How do you propose to do that without changing the package name, and
> without leaving old System.map junk around for eternity? I don't see how
> it can be possible.
> 
> (This is exactly the same question as Matthew asked, of course; but it
> is an important question relative to this ITP and I want to see it
> answered.)

I don't like turning this ITP into a technical discussion to prove either
my dessign is consistent or I'm capable as a maintainer. However I'll respond
to your question this time:

  Place the package files in /usr/lib, and copy them conditionaly (debconf)
  into /boot. The debconf question would properly explain that if per chooses
  to update it, then the system must be rebooted promptly.

Another option:

  Place the package files in /boot, but save a backup of them before (preinst).
  Then prompt the user to reboot through debconf.

Or even a combination of the two.

> > You're mixing trivial maintainer issues with this ITP. It's very pity
> > of you if you're doing it on purpose.
> 
> You're proposing a packaging scheme where the package name is not
> changed for new kernel versions. It is entirely legitimate for people to
> bring up potential problems with this scheme. I'm disappointed that you
> feel it necessary to brush them off just to railroad your proposal
> through.

I don't feel it necessary. But this is not the first trivial maintainer issue
I'm being pointed at in this ITP, and I'm getting the impression that some
people are doing it deliberately.

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