Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 3 Jun 2019 14:32:35 +0200
From:   Lukas Czerner <lczerner@redhat.com>
To:     Theodore Ts'o <tytso@mit.edu>
Cc:     linux-ext4@vger.kernel.org, Jan Kara <jack@suse.com>
Subject: Re: How to package e2scrub
Message-ID: <20190603123235.ajoa4b54w75xvppu@work>
References: <20190529120603.xuet53xgs6ahfvpl@work>
 <20190529235948.GB3671@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190529235948.GB3671@mit.edu>
User-Agent: NeoMutt/20180716
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Wed, May 29, 2019 at 07:59:48PM -0400, Theodore Ts'o 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....

Yeah, I've heard from two people and it was all about the service being
enabled by default when installing/updating e2fsprogs which for them was
very much unexpected. They were the types of people what want to have as
much controll as they can so they were annoyed by that and immediatelly
disabled the service :)

> 
> > 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".)

That's the suggestion for rpm packages in fedora - not enabling services by
default. I am still not decided about this since installing separate service
package is strong enough of a hint that user probably want to enable it.

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

Yeah, commenting out the crontab entry sounds like a good way to go
about it.

> 
> What do folks think?
> 
> 					- Ted