Updating of pci.ids in Etch
Andi requested I forward this pair of emails to debian-release;
if you wish to reply to anything in here, please keep
pkg-pciutils-discuss@lists.alioth.debian.org in the cc as I don't read
debian-release (and was sadly unaware of it, or I would have cc'd it in
the first place).
----- Forwarded message from Matthew Wilcox <matthew@wil.cx> -----
From: Matthew Wilcox <matthew@wil.cx>
To: aba@not.so.argh.org, zobel@debian.org
Cc: pkg-pciutils-discuss@lists.alioth.debian.org
Subject: [Pkg-pciutils-discuss] Updating of pci.ids in Etch
Hi Andi, Martin
We have persistent requests to update pci.ids either automatically or
frequently, and as stable release managers, I wanted to ask your opinions
on how best to handle the situation.
Some misc facts:
- pci.ids is currently 404k of the 660k pciutils binary package
- The pciutils udeb contains a stripped-down pci.ids file which is a mere 236k
- pci.ids is updated regularly upstream and can be retrieved from
pciids.sf.net with a script (update-pciids).
Now, since pci.ids is only useful for mapping numbers to names, updating
pci.ids doesn't help us support more hardware. It does help us get better
bug reports, and helps some users figure out where best to direct their
bug reports, or help themselves.
Some people want to update pci.ids on a regular basis. However, I think
these people are misguided for a number of reasons. If we have a cronjob
that goes and fetches a new pci.ids once a week from sourceforge, we're
effectively conducting a DDoS attack (see also: mythtv users and embedded
ntp implementations). Also, updating pci.ids on a system which has all
of its hardware already recognised is pointless.
The people who actually benefit from pci.ids being updated are those doing
new installs, and they need it updated in d-i, which implies updating
the udeb. I presume d-i gets rebuilt for each minor release, and if so,
that seems like the best time to push pci.ids updates into stable.
I'm told that volatile.debian.net isn't set up to support udebs, and
anyway, it's unclear to me that d-i should be pulling from volatile.
We can separate out pci.ids from pciutils easily enough, even making it
a separate source package, and binary-all so as to not require rebuilds.
But what do you want to do? If you want to declare this an insufficiently
interesting problem to deal with, that's fine. But in that case, I'd
like special dispensation to get pci.ids updated as close to release
as possible. Maybe separating out pci.ids into binary-all would help
most with that.
----- End forwarded message -----
----- Forwarded message from Andreas Barth <aba@not.so.argh.org> -----
From: Andreas Barth <aba@not.so.argh.org>
To: Matthew Wilcox <matthew@wil.cx>
Cc: zobel@debian.org, pkg-pciutils-discuss@lists.alioth.debian.org
Subject: Re: Updating of pci.ids in Etch
Hi,
* Matthew Wilcox (matthew@wil.cx) [060616 20:20]:
> Some people want to update pci.ids on a regular basis. However, I think
> these people are misguided for a number of reasons. If we have a cronjob
> that goes and fetches a new pci.ids once a week from sourceforge, we're
> effectively conducting a DDoS attack (see also: mythtv users and embedded
> ntp implementations). Also, updating pci.ids on a system which has all
> of its hardware already recognised is pointless.
Agreed. It might still be useful to have a script in examples or so
(which you probably have anyway, I was just too lazy to check :).
> The people who actually benefit from pci.ids being updated are those doing
> new installs, and they need it updated in d-i, which implies updating
> the udeb. I presume d-i gets rebuilt for each minor release, and if so,
> that seems like the best time to push pci.ids updates into stable.
Actualy, d-i wasn't rebuild up to now. d-i will be rebuid first for r3,
which is a new experience for us all.
> I'm told that volatile.debian.net isn't set up to support udebs, and
> anyway, it's unclear to me that d-i should be pulling from volatile.
Well, it's not a big act to add udebs there - probably the large problem
is to add that to d-i (but don't ask me on that - I'm not on the d-i
team :).
> We can separate out pci.ids from pciutils easily enough, even making it
> a separate source package, and binary-all so as to not require rebuilds.
I think that's helpful anyways.
> But what do you want to do? If you want to declare this an insufficiently
> interesting problem to deal with, that's fine. But in that case, I'd
> like special dispensation to get pci.ids updated as close to release
> as possible. Maybe separating out pci.ids into binary-all would help
> most with that.
Well, I think it might be useful to make pci.ids a seperate package -
that allows a very late update of the pci.ids for etch, and makes it
also easier to update them on a point release. I think updating on a
point release is ok with us (but I don't decide that alone w/o giving
zobel the chance to disagree with me :) - as long as it has benefits
(and on that question, we of course relay on you as maintainer). If and
how to best update the udeb package, we need input from the d-i people;
as long as they're happy, we are happy also.
BTW, IMHO it would be useful to re-send your and this mail to
debian-release@lists.debian.org - please feel free to do so if it's also
ok to you.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
----- End forwarded message -----
Reply to: