Update pciutils from 3.5.6 to 3.6.3

[pmenzel]

@wwwutz volunteered to keep the PCI IDs up-to-date, so keep the database in the package.

Tested on rabammel and amaru. On amaru, the Intel graphics device is correctly named now.

00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Desktop 9 Series) (rev 02)

[wwwutz]

I don't like the idea of maintaining files on the distmaster via spurious commands. There are far too many files already 'distmaster-only'. We lose information about where the files come from ( bee query bla ) or how to (re-)create them ( cat bla.be0 ).

Why not just update the be0-revision ? The update of the pci-ids won't be done on a daily base.

[pmenzel]

That a (soon outdated) snapshot of the ID database is shipped in the source archive is just a convenience, but gets in the way for distributions in my opinion. I do not see the point of rebuilding source files just to get updated IDs. One could create an extra package with just one file as Debian does it.

But, in practice for MarIuX, once the database is taken out and during installation newly created, the next time we want to update the ID database, we will see, that it’s not packaged, and quickly find out, that just one command needs to be executed on the distmaster. No package churn, no merge/pull requests, and so on.

[donald]

Perhaps build a database of all files, which are not installed by a bee package and teach "bee query" to show the sources of these files, too?

[wwwutz]

That a (soon outdated)

Lets see how often this happens:

-rw-r--r-- 1 root root 259509 Oct  4  2010 /src/mariux/beeroot/packages/pciutils-3.1.7-0.x86_64.bee.tar.bz2
-rw-r--r-- 1 root root 263262 Aug 18  2011 /src/mariux/beeroot/packages/pciutils-3.1.7-1.x86_64.bee.tar.bz2
-rw-r--r-- 1 root root 304887 Oct  8  2014 /src/mariux/beeroot/packages/pciutils-3.2.1-0.x86_64.bee.tar.bz2
-rw-r--r-- 1 root root 321992 Aug 12  2016 /src/mariux/beeroot/packages/pciutils-3.5.1-0.x86_64.bee.tar.bz2
-rw-r--r-- 1 root root 337874 Jun 18  2018 /src/mariux/beeroot/packages/pciutils-3.5.6-0.x86_64.bee.tar.bz2
-rw-r--r-- 1 root root  96108 Jan  7 12:46 /src/mariux/beeroot/packages/pciutils-3.6.2-0.x86_64.bee.tar.bz2

Six times in ten years.

/src/mariux/beeroot/packages/pciutils-3.1.7-0.x86_64.bee.tar.bz2
-rw-r--r-- root/root    638910 2010-10-04 17:00 /usr/share/pci.ids
/src/mariux/beeroot/packages/pciutils-3.1.7-1.x86_64.bee.tar.bz2
-rw-r--r-- root/system  638910 2011-08-18 12:19 /usr/share/pci.ids
/src/mariux/beeroot/packages/pciutils-3.2.1-0.x86_64.bee.tar.bz2
-rw-r--r-- root/system  875217 2014-10-08 13:30 /usr/share/pci.ids
/src/mariux/beeroot/packages/pciutils-3.5.1-0.x86_64.bee.tar.bz2
-rw-r--r-- root/system 1019974 2016-08-12 16:00 /usr/share/hwdata/pci.ids
/src/mariux/beeroot/packages/pciutils-3.5.6-0.x86_64.bee.tar.bz2
-rw-r--r-- root/system 1088495 2018-06-18 14:34 /usr/share/hwdata/pci.ids
/src/mariux/beeroot/packages/pciutils-3.6.2-0.x86_64.bee.tar.bz2

On every update, the source release version and pci.ids changed. There is no exclude in Distfile so we lived about 10 years with 6 different versions.

[wwwutz]

One could create an extra package with just one file as Debian does it.

Why ? As shown before this just happened 6 times in TEN years.

... the next time we want to update the ID database,

When will this happen ? In 1.6 Years ? I would think the source would changed and needed to be updated until then, too.

we will see, that it’s not packaged

How do we find out it's not packaged ? What commands would an admin have to enter to find out it's not packaged ? It's much easier to find it is packaged, than the opposite.

... and quickly find out, that just one command needs to be executed on the distmaster.

How do I find out what command is linke to create this file ? For me, it's bee install. Even if they change the format of the file: bee update.

update-pciids is depended on some internet URL. As is the source. So what if the connected server is unreachable ? Or they change location. Look at this nice example:

#   system("wget -N http://standards.ieee.org/regauth/oui/oui.txt");
#   system("wget -N http://standards-oui.ieee.org/oui/oui.txt");
    system("wget -N http://linuxnet.ca/ieee/oui.txt.bz2");

These changes render the update command useless. You have to touch the source.

No package churn, no merge/pull requests, and so on.

vi; [cursor up]; [return];

Questioning merge/pulls ?

[wwwutz]

Perhaps build a database of all files, which are not installed by a bee package and teach "bee query" to show the sources of these files, too?

Who updates the database ? A cron job ? Should it track changes to these files ? Keep some history ? Where do we put this database. Would it honor Distfile-excludes ? Then on which host should it be created ?

Why should we make already solved problems more complicated ?

There is a file somewhere, it belongs to a bee file and is mentioned in /usr/share/bee/*/CONTENTS. That's it. Easy-Peasy. We even have a checksum. We would find tampering.

[donald]

Thats more a general idea, not strictly related to this PR. We already have many many files on the distmaster which do not originate from bee packages. Some do have other defined sources (mxtools), some are created by runtime or boot tools (/etc/exports), some where manually created in ancient times and are not tracked at all (/etc/resolv.conf). So a database which enumerate the source for every file might be nice. No, it should not be build by cron and document the moving status quo which exists on the filesystem anyway. Registering a file would be done by the tool which installs it, or by an administrator. We could create a notification if unregistered files appear.

[pmenzel]

1. The reason for only six updates in the last years might be, that updating the package just for a more recent file is too much work, and people just run update-pciids or lspci -q to scratch their itch.

2. Again, pciutils and the PCI ID database are separate. pciutils last release is from 2018, while the database was last updated on January 12th, 2020.

[wwwutz]

I'm not questioning a last updated date ? You are creating an external dependency to a system file. One solution would be to

1. move it somewhere in /var, modify the sources and/or dist a symlink and update var 'manually
2. move it to /project/config, create it there and dist it. needs Distfile exception.
3. put it in a separate bee file. no win.
4. rebuild and increase bee and update as usual.

I will hardly accept any new Distfile exception.

You found a solution, even two, so why not stick with it.

If you think updating the bee package is too much work, feel free to delegate this work to me. I'm happy to do this for you with every update of pciids. Count on me.

You still owe me answers to

1. How do we find out it's not packaged ?
2. What commands would an admin have to enter to find out it's not packaged
3. How do I find out what command is needed to create this file ?
4. Why not bee update
5. So what if the connected server is unreachable ?
6. What if they change location ?
7. What if the change the format ?

All this hassle because you don't want to 'quickfix' use update-pciids ? And be reminded to update the package ?

[pmenzel]

I'm not questioning a last updated date ? You are creating an external dependency to a system file. One solution would be to

What is the dependency? The system file is there.

1. move it somewhere  in  `/var`, modify the sources and/or dist a symlink and update `var` 'manually

It’s only updated, if you run a command. So hardly belongs into /var.

2. move it to /project/config, create it there and dist it. needs Distfile exception.

Isn’t that for things, how we configure MarIuX?

3. put it in a separate bee file. no win.
4. rebuild and increase bee and update as usual.

Too much hassle.

I will hardly accept any new Distfile exception.

This file is supposed to be disted.

You found a solution, even two, so why not stick with it.

Because I will forget about those.

If you think updating the bee package is too much work, feel free to delegate this work to me. I'm happy to do this for you with every update of pciids. Count on me.

Thank you for the offer. I’ll guess I’ll take you up on that.

You still owe me answers to

1. How do we find out it's not packaged ?

sudo bee query pci.ids does not list the file. (Look at the bee file.)

2. What commands would an admin have to enter to find out it's not packaged

man pci.ids (present in 3.6.3 now). On well configure GNU/Linux system apropos pci.ids also return update-pciids.

3. How do I find out what command is needed to create this file ?

Ditto.

4. Why not `bee update`

Too much work, and did not work out. You need to change the bee file, to additionally get the latest version. So, the package is not reproducible, as it can download newer IDs, if you run it later.

5. So what if the connected server is unreachable ?

You cannot update that file. But no downside compared to outdated.

6. What if they change location ?

What location? You still have at least the IDs of the last release.

7. What if the change the format ?

Format of what? Very theoretical question. You go back to the latest working version from the backup. But they will maintain compatibility.

All this hassle because you don't want to 'quickfix' use update-pciids ? And be reminded to update the package ?

Yeah. Run lspci and notice, that you get the old IDs again, because it was disted back or you are on a different system.

Several of your concerns (change format, server not reachable) apply to shipping it in the bee package too. My solution is not worse.

[pmenzel]

I put the file back into the package.

[wwwutz]

Thanks. Feel free to merge, drop me a message so I'll rebuild on db update.