On Wed, May 29, 2019 at 11:21:11AM -0700, Darrick J. Wong 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. > > Funny, xfs has the same conundrum. Adding Eric & xfs list to cc... > > > 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. > > Yeah, e2scrub is bitrotting rather faster than I had thought it > would... but it's only available in Debian unstable. > > > 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). > > Indeed. Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find > that name to be very clunky and would have preferred "xfs_scrub". > > > I was thinking about e2scrub-service for systemd service or e2scrub-cron > > for the cron job. What do you think ? > > In /theory/ the cronjob support in e2scrub (and xfs_scrub) were designed > to step out of the way if systemd is running, so at least in theory (on > Debian anyway) the two can be in the same package with the end result > being that e2scrub runs weekly in the background. I've not tried in > rhel/suse environments, however. > > I also don't see the point of supporting cron *while* systemd is active. > That increases the amount of corner-case testing we have to do, for > little gain. It's enough work to maintain the systemd-with-timers and > sysvinit-with-cron scenarios. Yeah, you're probably right. I just wanted to give people some options if they do not want (for whatever reason) to use systemd. Container environment might be a good example of that, but I am not at all sure how well is lvm2 supported in containers. > > If you're worried about the stability of systemd timer code, systemd's > timer support has been stable enough to run e2scrub_all/xfs_scrub_all on > my systems since late 2015, and I have no interest in supporting either > on a pre-2016 distro. Practically speaking, I guess that RHEL8, SLES16, > and Ubuntu 20.04 will be the first LTS distros to support e2scrub at > all. > > (As for xfs_scrub, it'll barely achieve alpha status in Linux 5.2...) > > > Also I decided not to package the cron job for now. But if I decide to > > package it in the future I'd like to change the e2scrub cron > > configuration so that it can run on the systems with systemd but make > > the package conflict with the e2scrub-service so that users are free to > > decide how they want to use it. > > If you do end up creating two packages I'd name the systemd one > e2scrub-systemd over e2scrub-service. Ok, thanks for suggestion. Andreas was suggesting naming it as part of e2fsprogs, that is - e2fsprogs-scrub but then it would be e2fsprogs-scrub-systemd and that sounds a bit convoluted to me. Thanks! -Lukas > > --D > > > Thoughts ? > > > > Thanks! > > -Lukas
