So my @world update today wants to rebuild logrotate, which now seems to pull in virtual/cron. But I had logrotate-3.8.9 already installed, with rotations invoked via systemd timer unit, and thus don't need a cron installed at all. So... go check the changelog. Hmm... funny, no changelog entries except for keywording since 3.8.9's introduction. Well, maybe the change is in an inherited eclass, but what sort of eclass change would add that dependency? Turns out it was *not* an eclass change after all, as a diff between my installed logrotate-3.8.9.ebuild (in the installed pkg database) and the updated in-tree version shows... + virtual/cron in the dependencies, in the ebuild itself. But according to the changelog, no changes other than keywording have been made since the introduction of that ebuild. What gives? Was this an unauthorized cracker change since the changelog says the change didn't happen when the ebuild clearly changed in the tree since I installed it? Maybe this bug should be filed as a security bug due to the evident intrusion? Haha only serious. Meanwhile, the virtual/cron dependency does make some sense as logrotate does need periodically invoked or it's useless, and the package isn't shipping systemd timer units to provide that functionality yet. I will of course package.provided it here, since I created the appropriate units and related invocation framework myself, but until logrotate is shipping such systemd timer units the dependency does make sense in general. However, AFAIK that dependency should be RDEPEND, not DEPEND, since there's obviously no reason to require it at build-time on a build-only system, only runtime, or the build would have failed on my system in the first place. And since the virtual/cron dep is DEPEND only ATM, wouldn't that mean binpkg installs don't pull it in and depclean can remove it once logrotate is built and installed? But needed or not, it's extremely annoying not to be able to read about the change, why it was made, and who made it, in the changelog! Please add an appropriate entry. When the migration to git happens, users should be able to git log the changes if they care, but that hasn't happened yet, so us users who /do/ care /do/ still depend on those changelog entries. Thanks. =:^)
(In reply to Duncan from comment #0) > So... go check the changelog. Hmm... funny, no changelog entries except for > keywording since 3.8.9's introduction. Well, maybe the change is in an > inherited eclass, but what sort of eclass change would add that dependency? > This change was reported in the changelog: 04 Apr 2015; Chema Alonso <nimiux@gentoo.org> logrotate-3.8.9.ebuild: Fix bug #485848 by Marek Mrva I included this change before package's stabilization. > But according to the changelog, no changes other than keywording have been > made since the introduction of that ebuild. > The ebuild was pushed on march the 1st: *logrotate-3.8.9 (01 Mar 2015) 01 Mar 2015; Chema Alonso <nimiux@gentoo.org> +logrotate-3.8.9.ebuild, +files/logrotate-3.8.9-Werror.patch, +files/logrotate-3.8.9-atomic-create.patch, +files/logrotate-3.8.9-fbsd.patch, +files/logrotate-3.8.9-ignore-hidden.patch, +files/logrotate-3.8.9-noasprintf.patch: Version bump. Fix bug #533992 > What gives? Was this an unauthorized cracker change since the changelog > says the change didn't happen when the ebuild clearly changed in the tree > since I installed it? Maybe this bug should be filed as a security bug due > to the evident intrusion? Haha only serious. > logrotate-3.8.9 was stabilized on amd64 and hppa some days after this change was pushed. Probably this caused the rebuild and pull of cron dependency in your system. > > Meanwhile, the virtual/cron dependency does make some sense as logrotate > does need periodically invoked or it's useless, and the package isn't > shipping systemd timer units to provide that functionality yet. I will of > course package.provided it here, since I created the appropriate units and > related invocation framework myself, but until logrotate is shipping such > systemd timer units the dependency does make sense in general. > Yeah, bug #525418 is dealing with this. > However, AFAIK that dependency should be RDEPEND, not DEPEND, since there's > obviously no reason to require it at build-time on a build-only system, only > runtime, or the build would have failed on my system in the first place. > And since the virtual/cron dep is DEPEND only ATM, wouldn't that mean binpkg > installs don't pull it in and depclean can remove it once logrotate is built > and installed? Totally right. My bad here. I'll fix it along the day. > > But needed or not, it's extremely annoying not to be able to read about the > change, why it was made, and who made it, in the changelog! Please add an > appropriate entry. When the migration to git happens, users should be able > to git log the changes if they care, but that hasn't happened yet, so us > users who /do/ care /do/ still depend on those changelog entries. Thanks. > =:^) The entry was added at proper time. Probably I'd had to wait for a quarantine period before requesting stabilzation, but this change is not so big and the ebuild it's been there for more than one month. Thanks for the report.
+ 09 Apr 2015; Chema Alonso <nimiux@gentoo.org> logrotate-3.8.9.ebuild: + Fix bug #545922 by Duncan +
(In reply to Chema Alonso from comment #1) > (In reply to Duncan from comment #0) > > > So... go check the changelog. Hmm... funny, no changelog entries except for > > keywording since 3.8.9's introduction. > > This change was reported in the changelog: > > 04 Apr 2015; Chema Alonso <nimiux@gentoo.org> logrotate-3.8.9.ebuild: > Fix bug #485848 by Marek Mrva Brown paper bag time. I seriously don't know how I could have missed that, but evidently I did. Sorry. =:^( > I included this change before package's stabilization. > > logrotate-3.8.9 was stabilized on amd64 and hppa some days after this change > was pushed. Probably this caused the rebuild and pull of cron dependency in > your system. Now I know why emerge --info output is recommended even when not directly needed. I'm on ~amd64 so got it before stabilization. But I have dynamic-deps turned off and changed-deps turned on, thus forcing rebuild of anything where deps change, which triggered when the virtual/cron dep was added. I simply didn't see the changelog entry corresponding to the virtual/cron dependency add, thus my confusion. Now that I see what was apparently there all the time... But I guess it's good that I didn't see it, as if I had, I'd have been unlikely to notice the DEPEND/RDEPEND mixup and file this bug. >> However, AFAIK that dependency should be RDEPEND, not DEPEND > > Totally right. My bad here. I'll fix it along the day. Thank you. And thanks for being gentle with my apparent blindness, more gentle than I deserve, certainly, and I apologize, both for the mistake I made, and the mistake I /almost/ made, before I reconsidered and toned down my original wording. Good thing too, as I'd have been hoist on my own petard! =:^\
No problem. Thank you for contributing to Gentoo Linux =P Cheers.
