Now the ebuild downloads pci.ids in src_unpack. I think it would be a better idea to setup a cron.weekly or cron.monthly job to keep the system updating even if pciutils itself does not update.
why not do both ... i'd opt for cron.monthly myself
Same thing applies to sys-apps/usbutils. In the cron we should probably account for the fact that /usr could be mounted read-only. We should have a copy of the files in the tarball so there isn't any pressing need to update it in the ebuild.
the bundled one in the tarball probably is newer than the snapshot we've been including historically ... in the past this made a lot more sense since the packages were never actually updated (took years between 2.1.11 and 2.2.0) fixed in cvs with monthly cronjobs
Since pciutils-2.2.3-r2 became just stable here, I did not hear about this change before. For people without flatrate or e.g. with an on-demand internet connection, it is not a good idea to have a cron-job checking for updates, in particular, if the hardware is fixed and so there is no real reason to update. Moreover, it was very strange to me that I was not even informed about the fact that my computer is now going to connect the internet automatically in a regular manner: If one does not read every single ChangeLog, one can only realize this by accident or by paranoic test programs. Of course, if the ebuild would print a corresponding message, one could delete the cron-job manually, but this is easily forgotten if e.g. pciutils is recompiled in an emerge -e world (e.g. for a gcc update). Therefore, I strongly suggest to make the installation of the cron-job dependent of some useflag. (BTW: Wouldn't it be more efficient and clearer to make a symbolic link in /etc/cron.monthly instead of a "dummy" script which just executes one command?)
did you read the ChangeLog ? because it says moving the pci ids update to cron
(In reply to comment #5) > did you read the ChangeLog ? because it says moving the pci ids update to cron >> "If one does not read every single ChangeLog" ... IMHO things like an automatic connection to the internet should not be hidden in a ChangeLog. In particular, pciutils used to be a "harmless" small package which probably many people installed "just for the case that someday more information is needed": Most people will just assume small bugfixes or supplements in the upgrade (who has the time to read every entry in every ChangeLog?) and not such a dramatic functionality change like a regular internet connection.
my bad, i'll rename the package to "pciutils-now-fetches-from-the-internet-via-a-cronjob" so hopefully users will realize that pciutils now fetches from the internet via a cronjob
vapier: to stop the whiners, and help those that don't have always-on internet, could you move the cronjob to a new package, and provide occasional updates of that package with copies of the pci.ids and usb.ids? This is the route I use to maintain spamassassin-rulesdujour. The auto-updater is there, and I update the bundled rules every 6 months too.
I did not want to attack anybody, I really just wanted to help improve. What is so bad about my suggestion for a "cronjob-fetch" USE-Flag (or - if you prefer - a "no-cronjob-fetch" USE-Flag)? Then the behavior is much more visible and simply (and permanently) customizable, and no additional package would be necessary. (Moreover, the same flag might also be used for other similar situations - I cannot judge whether it would even be reasonable for spamassassin - so the flag might even become global eventually.) In any case, an occasional update - as Robin suggested - might be useful: There are Gentoo systems which are e.g. behind a firewall or on a laptop or with only sporadic internet connection (no dial-on-demand) for which the cron-job might always fail. Concerning the sarcastic remark about information policy: My experience is that people read pkg_postinst() { einfo "..." } rather often, but it is hard to judge how reliable this experience is.
i'm not forking a package just for the cronjob file a generic USE flag like "networked-cronjob" for all packages to leverage would be ideal ... we just default it to on and people can put it in their global USE to turn it off
*** Bug 161296 has been marked as a duplicate of this bug. ***
*** Bug 164875 has been marked as a duplicate of this bug. ***
*** Bug 168003 has been marked as a duplicate of this bug. ***
