Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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