[pkg-wpa-devel] Bug#360387: Lowering severity (was: reopening)

[Joerg Friedrich]

Hi!

Reinhard Tartler schrieb am Donnerstag, 13. April 2006 um 10:14:21 +0200:
> On Thu, Apr 13, 2006 at 08:03:03AM +0200, Joerg Friedrich wrote:
> > Other package maintainers seems to put lots of work in creating an
> > upgrade path if they do not support an old configuration.
> 
> There is no clean upgrade path from the old init script method to the
> current solution. well spotted.

Thanks. 

> 
> > The new wpasupplicant does not even notify (by debconf).
> > It will just stop working.
> 
> this is commonly considered as debconf abuse. We don't do the same
> mistake as others. At least in debian, users are expected to read
> NEWS.Debian, which clearly documents what's happened.

Ok, Understood. So it's even more important to find a solution
to manage these upgrades.

> > Serverity grave was set before my reopening.
> 
> as bug (re)openor it is your responsibility to title and set severity
> appropriately. Given that you knew our opinion on this matter in
> advance, I have to assume that you just insist on your opinion and just
> wan't the old situation back, without caring for our motivation in
> making things like they are (yes, there are reasons). This is my
> response on that.
> 
> > I consider this bug at least 
> > 
> > important
> >     a bug which has a major effect on the usability of a package,
> >     without rendering it completely unusable to everyone.
> > 
> > maybe even serious, but I do not know Debian Policy well enough to
> > judge.
> 
> This is getting silly. Instead on helping with a solution on this
> issue, you rather keep on arguing about this bug severity? 

Supporting both ways daemon-style and interfaces-style is a solution to
me.

> > > Since we ship the init script in
> > > usr/share/doc/wpasupplicant/examples along with ready to copy and paste
> > > instructions how to activate it, I consider this issue easy to fix on
> > > both user and maintainer side.
> > 
> > Why don't support both ways of configuring wpa-supplicant?
> > Just ship the init-script working in /etc/init.d and disable it by
> > /etc/defaults/wpasupplicant as it is done in the sarge package?
> > Advantage: you can restart wpasupplicant in the maintainer-scripts on
> > package update.
> 
> It just confuses new users of wpasupplicant for no real benefit. 

the benefit is the support of configurations you'll find on some
websites.

> > common practice, just 'grep -ir enable /etc/defaults'
> > I'm sure, you also have some packages installed which use this way.
> 
> As said above, we don't want to make the same mistake like others. I
> don't find this solution very 'debian'-ish, and consider this as the
> last resort only. 

I have no idea, why this is a mistake.
OK, instead of using an enable mechanism in /etc/defaults you can ask
the user by debconf whether he wants to use the old or the new way.
And based on this answer you can call the appropriate update-rc.d
command.

But maybe this would be another debconf abuse?


> Please look at the archives of this list, I outlined that we could move
> this kind of setup (wpasupplicant+ifupdown+guessnet+configuration) into
> a package on it's own.

I do not think that ftp-master would accept a package which solely
consists of an init-script. I do not see, why one package cannot serve
more than one configuration. 

> Why not helping me on this rather than bitching
> about broken upgrade paths to nirvana or bug severities?

-- 
Jörg Friedrich

There are only 10 types of people:
Those who understand binary and those who don't.