[MacPorts] #52376: usbutils @007 update USB ID database to version 2016.09.07
#52376: usbutils @007 update USB ID database to version 2016.09.07 ---------------------------------+-------------------------------- Reporter: leonardo.schenkel@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: usbutils ---------------------------------+-------------------------------- The current port uses the USB ID database embedded in the source code, which is from 2013. I have attached a patch that replaces the database with the latest version, 2016.09.07. -- Ticket URL: <https://trac.macports.org/ticket/52376> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Changes (by larryv@…): * keywords: => haspatch * cc: bernhard@… (removed) * version: 2.3.4 => * owner: macports-tickets@… => bernhard@… Comment: Where does this database come from? Could we could download it instead of adding it to everyone’s ports trees? -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:1> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by leonardo.schenkel@…): It comes from: http://www.linux-usb.org/usb.ids Sure, we can download it from there at build time. The reason I didn't do it was because I thought that was an anti-pattern. I have attached a new patch that does it — maybe there is a more idiomatic MacPorts way instead that doing a `curl`? In case we do want to include the DB in the ports tree, if I compress it with `gzip -9` it becomes a little bit less than 200K. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:2> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by leonardo.schenkel@…): Another reason for why I'm not sure if it's a good idea to download the DB at build time is because the build becomes not reproducible and if `linux- usb.org` is not online (or the file available or not well-formed) then the package cannot be built or will not work at runtime. Not good attributes in my opinion. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:3> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by larryv@…): Replying to [comment:2 leonardo.schenkel@…]:
Sure, we can download it from there at build time. The reason I didn't do it was because I thought that was an anti-pattern.
No, it’s the opposite—putting non-patches in `filespath` is unorthodox. Very few ports do this.
I have attached a new patch that does it — maybe there is a more idiomatic MacPorts way instead that doing a `curl`?
The usual method is to add the additional files to `distfiles` and set `extract.only`. You can find examples by searching the ports tree for “extract.only”. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:4> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by larryv@…): Replying to [comment:3 leonardo.schenkel@…]:
Another reason for why I'm not sure if it's a good idea to download the DB at build time is because the build becomes not reproducible
The one issue I can think of is that the filename doesn’t include version information, so every update would be a [[PortfileRecipes#stealth- updates|stealth update]]. It’s possible to work around this.
if `linux-usb.org` is not online (or the file available or not well-formed) then the package cannot be built or will not work at runtime. Not good attributes in my opinion.
This is true of all distfiles, including source tarballs. That’s why we mirror distfiles. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:5> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by larryv@…): Replying to [comment:2 leonardo.schenkel@…]:
Sure, we can download it from there at build time. The reason I didn't do it was because I thought that was an anti-pattern.
I just realized what you meant by this. Yes, downloading during the build phase is an antipattern. I’m recommending downloading it during the fetch phase as just another distfile. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:6> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by leonardo.schenkel@…): OK, thanks for the tips. I will implement a different solution later today as you have described and re-submit the patch. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:7> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by leonardo.schenkel@…): After some experimentation, I think the best option is to separate the USB ID database from `usbutils` by creating a new port `usbids` for just the USB ID DB and making `usbutils` depend on it. I have used the "deactivate" hack described in https://trac.macports.org/wiki/PortfileRecipes#deactivatehack since the new port will take over the `${prefix}/share/usb.ids.gz` file. Since `usb.ids` is an unversioned distfile it forces the port to use a `dist_subdir` of `${name}/${version}`. If the DB was not split from `usbutils` this would unnecessarily waste space in all mirrors due do the fact that there would be a copy the `usbutils` source for each version of the port even though the source tarball does not change and does not suffer from the problem. Splitting the two into different ports is the most elegant and straightforward solution to me. Not coincidentally, this was the approach taken by the FreeBSD port as well. I took inspiration from it and named the port similarly. I'm attaching a new patch. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:8> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by leonardo.schenkel@…): I had to update the patch once more to get rid of a warning that the current USB ID database triggers on `usbutils`. I had to patch the DB to remove the offending line. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:9> MacPorts <https://www.macports.org/> Ports system for macOS
#52376: usbutils @007 update USB ID database to version 2016.09.07 ----------------------------------+------------------------ Reporter: leonardo.schenkel@… | Owner: bernhard@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: usbutils | ----------------------------------+------------------------ Comment (by leonardo.schenkel@…): Is there anybody who could review this please? I got no replies for 8 days now. -- Ticket URL: <https://trac.macports.org/ticket/52376#comment:10> MacPorts <https://www.macports.org/> Ports system for the Mac operating system
participants (1)
-
MacPorts