[Pkg-pciutils-discuss] Re: Updating of pci.ids in Etch

[Matthew Wilcox]

On Fri, Jun 16, 2006 at 08:37:08PM +0200, Andreas Barth wrote:
> Hi,
> 
> * Matthew Wilcox (matthew at 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 :).

We probably should put one in examples; I'll add that to the todo.

> > 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 pretty sure pciutils doesn't have a udeb for sarge, but it does for
etch, so I don't think this is something that needs to be cared about
for the Sarge r3 release.  I wish you the best of luck with that ;-)

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

OK, I'll harass those fine people on debian-boot, once we've reached
consensus on the later portions of this mail.

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

OK.  I'm reluctant to proliferate packages unnecessarily, but given that
it's almost 2/3 of the package, and other packages also use pci.ids, I
think the benefits outweigh the disadvantages.

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

I agree with your opinion here, and it's also the way I've been leaning
while thinking about it over the last week or two.  I'd like to give
people with opposing points of view the chance to chime in, but if I
don't hear any dissent in the next week, I'll make this change in
packaging for the 2.2.3-1 releasae.

> BTW, IMHO it would be useful to re-send your and this mail to
> debian-release at lists.debian.org - please feel free to do so if it's also
> ok to you.

Done.  If I'd realised it existed, I would have done that in the first
place ;-)