Rather than naming the packages "e2scrub-*" it makes more sense to me to use "e2fsprogs-scrub" so that it is clear this is a sub-package of e2fsprogs? Or is the thought that the scrub functionality might move out of e2fsprogs and xfsprogs at some point in the future. Cheers, Andreas PS: I'd agree with Darrick that "xfsprogs-scrub" is probably a better name. > On May 29, 2019, at 17:59, Theodore Ts'o <tytso@xxxxxxx> wrote: > >> On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote: >> Hi guys, >> >> I am about to release 1.45.2 for Fedora rawhide, but I was thinking >> about how to package the e2scrub cron job/systemd service. >> >> I really do not like the idea of installing cron job and/or the service as >> a part of regular e2fsprogs package. This can potentially really surprise >> people in a bad way. >> >> Note that I've already heard some complaints from debian users about the >> systemd service being installed on their system after the e2fsprogs >> update. > > One of the reasons I deliberately decided to enable it for Debian > Unstable was it was the best way to flush out the bugs. :-) > > Yeah, Debian Unstable users are my guinea pigs. :-) Doesn't it work > that way with Fedora and RHEL? :-) > > BTW, The complaints were mostly from e2scrub_all not working correctly > if certain packages weren't installed, or if the LVM package was > installed, but there were no LVM volumes present, etc. The other > complaint I got was when there was no free space for the snapshot. > I'm kind of hopeful that I've gotten them all at this point, but we'll > see.... > >> What I am going to do is to split the systemd service into a separate >> package and I'd like to come to some agreement about the name of the >> package so that we can have the same name across distributions (at least >> Fedora/Debian/Suse). > > Hmm.... what keeping the service as part of the e2fsprogs package, but > then not enabling out of the box. That is, require that user run: > > systemctl enable e2scrub_all.timer > > in order to actually get the feature? (They can also disable it using > "systemctl disable e2scrub_all.timer".) > > As far as the cron job is concerned, we could just leave the crontab > entry commented out by default, and require that the user go in and > edit the /etc/cron.d/e2scrub_all file if they want to enable it. Not > packaging it also seems fine; Debian's support for non-systemd > configurations is at best marginal at this point, and while I'm not a > fan of systemd, I'm also a realist... > > What do folks think? > > - Ted