[bug#54069,0/2] gnu: pciutils: Unbundle pci.ids and use latest.

Completely untested but I needed pci.ids for something and discovered pciutils bundles an old version so I made this patch as something of a suggestion. Looks like it would be a core-updates change.
  

Hi Brendan,

> Completely untested but I needed pci.ids for something and discovered pciutils bundles an old version so I made this patch as something of a suggestion. Looks like it would be a core-updates change.

Thanks for this possibility, I've actually had to address something similar in https://issues.guix.gnu.org/53015 where I made a pciutils variant for this purpose. The patch is unmerged currently though.

I think that would work short term for our packaging needs and, as you say, make this bigger change for core updates (or wherever it will best fit). I haven't reviewed this patch, but in this way I think any updates to hwdata will cause pciutils to rebuild, which has many dependents. I'm not sure what is best, maybe: have pciutils use a frozen version of the hwdata with the separate package being a standalone more up to date data?

By the way, I do see in pciutils that share/hwdata/pci.ids.gz though admittedly I never checked to see if that really is gziped. Packages that want a plain pci.ids did not like it though (maybe just from file name?).

Would be great to have others chime in on what the longer term fix would be, in the short term a pciutils variant and/or hwdata standalone package would be helpful.

John
  

Hi Brendan and Maxim,

I'm aware of a couple of programs that want to use the plain pci.ids. True, they could use pciutils for that, but pci.ids is very simple, just a list of hardware ids paired with manufacturer/device names. While we can see if upstream for these programs will move to using pciutils, I could see reasons for not wanting the dependency or wanting more current info (especially in Guix where we would only update pciutils on core-updates).

So I would find the separate hwdata package useful for a few packages I have, like mangohud (pending review) and corectrl (not submitted yet). I have to check, but they might only want pci.ids and not anything in pciutils anyway. Also, hwdata provides more data than just pci.ids, which we don't have packaged for Guix as far as I know.

As for pciutils itself, I don't have any strong feelings on its pci.ids. Unbundling the included (old) info and using a hwdata package as input makes sense to me and is more flexible. On core-updates we can make that change for pciutils, where at some point we'd want to freeze what hwdata version it uses. Meanwhile, hwdata can be updated regularly (looks like monthly releases) for up-to-date data.

I think this would keep pciutils small (zipped pci.ids), unbundled/more up to date, and give us the hwdata as a useful package to use.

WDYT?
  

Hi John,

John Kehayias <john.kehayias@protonmail.com> writes:

> Hi Brendan and Maxim,
>
> I'm aware of a couple of programs that want to use the plain
> pci.ids. True, they could use pciutils for that, but pci.ids is very
> simple, just a list of hardware ids paired with manufacturer/device
> names. While we can see if upstream for these programs will move to
> using pciutils, I could see reasons for not wanting the dependency or
> wanting more current info (especially in Guix where we would only
> update pciutils on core-updates).
>
> So I would find the separate hwdata package useful for a few packages
> I have, like mangohud (pending review) and corectrl (not submitted
> yet). I have to check, but they might only want pci.ids and not
> anything in pciutils anyway. Also, hwdata provides more data than just
> pci.ids, which we don't have packaged for Guix as far as I know.
>
> As for pciutils itself, I don't have any strong feelings on its
> pci.ids. Unbundling the included (old) info and using a hwdata package
> as input makes sense to me and is more flexible. On core-updates we
> can make that change for pciutils, where at some point we'd want to
> freeze what hwdata version it uses. Meanwhile, hwdata can be updated
> regularly (looks like monthly releases) for up-to-date data.
>
> I think this would keep pciutils small (zipped pci.ids),
> unbundled/more up to date, and give us the hwdata as a useful package
> to use.

I think your proposition makes a lot of sense; the handful of
applications wanting raw pci.ids can have it via hwdata, while our
pciutils package can take (a frozen/fixed variant of hwdata) as an input
to a get a newer yet compressed pci.ids.gz file.

Seems a win/win solution to me!

Thank you,

Maxim
  

Hi Maxim,

------- Original Message -------

On Tuesday, February 22nd, 2022 at 4:00 PM, Maxim Cournoyer wrote:

> I think your proposition makes a lot of sense; the handful of
> applications wanting raw pci.ids can have it via hwdata, while our
> pciutils package can take (a frozen/fixed variant of hwdata) as an input
> to a get a newer yet compressed pci.ids.gz file.
>
> Seems a win/win solution to me!
>

Great! Brendan do you want to update your patches if you agree with this approach? I will test hwdata later for my mangohud patch, but since it is a simple copy install, I don't anticipate any problems.

Oh, and if I understand correctly, keeping pciutils with a pci.ids.gz would avoid a profile collision with hwdata's pci.ids (so you can have both pciutils and the extra data of hwdata), right? Which would also be good.

Thanks everyone,
John
  

Hi,

John Kehayias <john.kehayias@protonmail.com> writes:

> Hi Maxim,
>
> ------- Original Message -------
>
> On Tuesday, February 22nd, 2022 at 4:00 PM, Maxim Cournoyer wrote:
>
>> I think your proposition makes a lot of sense; the handful of
>> applications wanting raw pci.ids can have it via hwdata, while our
>> pciutils package can take (a frozen/fixed variant of hwdata) as an input
>> to a get a newer yet compressed pci.ids.gz file.
>>
>> Seems a win/win solution to me!
>>
>
> Great! Brendan do you want to update your patches if you agree with
> this approach? I will test hwdata later for my mangohud patch, but
> since it is a simple copy install, I don't anticipate any problems.
>
> Oh, and if I understand correctly, keeping pciutils with a pci.ids.gz
> would avoid a profile collision with hwdata's pci.ids (so you can have
> both pciutils and the extra data of hwdata), right? Which would also
> be good.

Indeed, I hadn't thought about this but it seems a nice property.

Maxim
  

I can report that the hwdata package installs for me, and a pending package (mangohud) that wanted the pci.ids file is happy with just hwdata; pciutils is no longer needed.

I did not do a review of the package definition other than this testing, but it worked and was useful for me.
  

I have used the ungexp suggestion Ludo made. I don't have any stance
on the gexp-ology business, so I just did that.
Feel free to change it however one wishes.

the hwata updates can go to master, but the rest should be considered for
core-updates i think?

I have fixed up the pciutils definiton a bit, where I had previously
removed the installation of a man page by mistake.

Implemented the #:target #f suggestion in hwdata, and fixed a small
mistake.

I was away from the computer for a week so I hope I haven't forgotten
to consider all feedback.

Updated hwdata to 357.