Bug#319583: pcmciautils packaging followup
owner 319583 Colin Watson <cjwatson@debian.org>
thanks
On Mon, Nov 21, 2005 at 08:35:49PM +0100, Mattia Dongili wrote:
> On Mon, Nov 21, 2005 at 12:58:48PM +0000, Colin Watson wrote:
> > Since we're about to switch to 2.6.15 as the default kernel in Ubuntu,
> > we needed pcmciautils, so I did a very quick packaging job on it, which
> > I'd like to move into Debian as long as I'm not stepping on anyone
> > else's toes:
> >
> > http://archive.ubuntu.com/ubuntu/pool/universe/p/pcmciautils/
> >
> > (may have moved to
> > http://archive.ubuntu.com/ubuntu/pool/main/p/pcmciautils/ by the time
> > you read this)
It has moved there now. More usefully, I've put all this in a bzr
(http://bazaar.canonical.com/Bzr) archive; I encourage anyone who wants
to do so to do development work in branches off that archive.
http://riva.ucam.org/~cjwatson/bzr/pcmciautils/upstream/
http://riva.ucam.org/~cjwatson/bzr/pcmciautils/debian/
> > However, I've done no real work on transitioning from pcmcia-cs; I
> > simply left pcmcia-cs there and made sure that both pcmcia-cs and
> > pcmciautils could be installed at the same time (which I think is a very
> > good property to have anyway). Further work on this would be useful. I'd
> > be happy to co-maintain this with a team.
>
> Be careful, if pcmcia-cs is purged after installing pcmciautils you lose
> /etc/pcmcia/config.opts :)
Right, that's why pcmcia-common (or, less ideally, some clever migration
scripts) will be needed.
> > > The first thing coming to my mind is having a pcmcia-common that does
> > > all the configuration stuff, and puts kernel-version-aware
> > > init/udev/hotplug(?) scripts around,
> >
> > I didn't bother with the hotplug scripts, since pcmciautils can only
> > easily be configured for one of udev or hotplug, and hotplug is going
> > away anyway. As far as I know there's no need for the udev scripts to be
> > kernel-version-aware because if your kernel is too old you simply won't
> > get the uevent.
>
> Yes, sorry for being unclear, I though only of the init-script being
> kernel-version aware so that it can be included into pcmcia-common.
I tweaked the Ubuntu pcmcia-cs init script to be a no-op on new kernels,
and added an init script to pcmciautils to handle the few things that
seem to still be needed and not be easily expressible as udev rules
(namely, modprobing pcmcia_core and the bridge module).
I deliberately made this a separate init script. I suppose the two could
be combined into one, but to be honest I don't really see the value;
this scheme works and avoids hairy conffile migration issues, and the
pcmciautils init script is much simpler when it doesn't have to deal
with all the legacy stuff.
> I don't know if it make sense but:
> - the user might want to not start pcmcia at boot (so no udev
> rules but an init-script is necessary)
That's probably best done by blacklisting the pcmcia_core module or
something along those lines; I believe Scott James Remnant has a pending
module-init-tools patch to allow that.
> - there's an easy way to load/unload pcmcia modules
> (eg: to have some powersaving or workaround common suspend
> (S3/S4) issues)
I haven't done unloading yet in the pcmciautils init script, but I'm
sure it could be done.
> I was also thinking about the upgrade path from sarge to etch where a
> kernel upgrade+reboot is already necesary because of udev.
> Now what happens? The careful user upgrades the kernel as a first step
> to something >2.6.13-rc1 and surprise! cardmgr doesn't work anymore
> and the network card used to download new packages doesn't come up
> (easily).
That's certainly not ideal, but even with a pcmcia-common there's no way
to make 16-bit cards work without installing pcmciautils. I think this
just has to be a release notes item.
> > > http://lists.infradead.org/pipermail/linux-pcmcia/2005-October/002820.html
> >
> > I can't help thinking that the init script proposed there shouldn't be
> > an init script at all. Wouldn't it be better to write udev rules for
> > this?
>
> Well, you already have udev rules, but quoting a comment within the
> script: "if you have a socket controller where the module cannot be
> loaded automatically by hotplug,...".
> There's still something obscure to me in that paragraph but I assume it
> can be true in some cases. :)
OK, that's true in the cases of non-PCI bridges (i82365, tcic).
> (I hope -again- to be able to spend more time here in the next days, but
> I can understand if you don't believe me anymore)
I have convenient access to three laptops with PCMCIA sockets, and four
PCMCIA network cards; this isn't bad but it's nowhere near complete
coverage. Co-maintenance here is a *good* thing, and hopefully with not
having to start from scratch on the packaging a number of people can get
involved with small tweaks (though of course many of the relevant small
tweaks should now live in the kernel).
Still, I think we've talked long enough about this, so I'm going to
upload my pcmciautils package so that at least everyone has a common
place to start, and folks with >= 2.6.13 can get their PCMCIA cards
running again. I haven't yet done an audit of /etc/pcmcia/config versus
kernel mappings, but Per's absolutely right that that needs to be done.
Then, with any luck, it's a simple matter of maintenance.
If there's enough interest here then perhaps we can create an Alioth
list for development.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: