Bug#219582: ITP: linux -- Linux 2.4 kernel
On Tue, Nov 11, 2003 at 12:21:32PM +0100, Robert Millan wrote:
> On Mon, Nov 10, 2003 at 02:23:52PM +0000, Colin Watson wrote:
> > 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.
No, I don't think I'm confused, I'm quite aware of where the discussion
came from, and it's not just a bug that prevents wchan from being
displayable. You actually acknowledged my comment about the more serious
problem later in your mail, so don't pretend that it doesn't exist up
here, please.
> > 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.
ITPs are frequently about ensuring that the design is valid! If you
thought they were just a rubber-stamping exercise, well, I'm sorry to
disappoint you, but peer review is an integral part of this project.
> 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.
Either satisfies the first part of my question, but at least your second
option doesn't satisfy the second part of my question. I'll repeat:
"without leaving old System.map junk around for eternity"
When would you clean up the "backups" you've created? It's very easy in
Herbert's scheme: you remove the package containing it. It doesn't seem
to be so well-organized in yours. The same goes for kernel modules, as
other people have mentioned: this is essentially the same problem (files
or directories that normally have the upstream version number in their
names) but more difficult.
As for the first option with debconf questions, well, that might work,
although I haven't fully thought out how it would interact with kernel
modules (what if users decide to copy hand-built modules into
/lib/modules, which is fairly common practice when testing things -
would they be removed when the newer version is installed? I'd hope not.
If not, when do you plan to remove modules that apply to older kernel
versions? Never?). There's been an increasing consensus over the years
that we should have fewer debconf questions, not more; perhaps this is
an exception, but I think it would be wise of you to seek review by
debconf experts before it enters the archive.
I'm not asking these questions to harass you: I'm asking them because I
genuinely have trouble believing that it's possible to solve them in a
high-quality way if you do not change the kernel package name from one
upstream release to the next. The main feature of your proposal from a
user's point of view seems to be that the package name will not be
changed from one upstream release to the next, and therefore I think it
is entirely appropriate for us to examine the implications of this
proposal on debian-devel in response to your ITP.
> > 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.
They're not trivial, and of course we're doing it deliberately. When
somebody posts an ITP that proposes to introduce an alternate packaging
of an important set of packages, it is entirely appropriate to examine
the consequences of that alternate packaging on debian-devel. Brushing
people's concerns off as "trivial" just reinforces the impression that
you don't really care about the consequences. I hope this isn't the
case.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: