On Fri 31-05-19 10:10:19, Theodore Ts'o wrote: > On Fri, May 31, 2019 at 12:07:13PM +0200, Jan Kara wrote: > > On Thu 30-05-19 09:51:55, Theodore Ts'o wrote: > > > On Thu, May 30, 2019 at 11:59:07AM +0200, Jan Kara wrote: > > > > Yeah, my plan is to just not package cron bits at all since openSUSE / SLES > > > > support only systemd init anyway these days (and in fact our distro people > > > > want to deprecate cron in favor of systemd). I guess I'll split off the > > > > scrub bits into a separate sub-package (likely e2fsprogs will suggest > > > > installation of this sub-package) and the service will be disabled by > > > > default. > > > > > > I'm not super-fond of extra sub-packages for their own sake, and the > > > extra e2scrub bits are small enough (about 32k?) that I don't believe > > > it justifies an extra sub-package; but that's a distribution-level > > > packaging decision, so it's certainly fine if we're not completely aligned. > > > > Yes, size is not a big concern but the scrub bits require util-linux, lvm, > > and mailer to work correctly and I don't want to add these dependencies to > > stock e2fsprogs package because some minimal installations do not want e.g. > > lvm at all. Granted these are just scripts so I could get away with not > > requiring e.g. lvm at all but it seems user-unfriendly to leave it up to > > user to determine that his systemd-service fails due to missing packages. > > So you're using an extra package to force the installation of the > necessary prerequisite packages, instead of the current approach where > we don't require them, but we just skip running the scrub if lvm and > util-linux are not present. I think both approaches makes sense. > > It's also a good point that we need to handle the case of a missing > sendmail intelligently. It looks like we currently skip sending mail > at all in the cron case, and in the case systemd case, we'll spew a > warning (which won't get mailed since there's no sendmail, but it does > mean some extra lines in the logfile). All of this being said, it's > not _completely_ useless to scrub without an mailer; we still mark the > file system as needing to be checked on the next boot. But it's > another argument that we shouldn't enable the service by default. > > For that reason, I'm not sure I'd want to force the installation of a > mailer, since someone might want to run e2scrub by hand, and > e2scrub_all every week w/o isn't a completely insane thing. But we > certainly should handle that case gracefully. Yeah, if the scripts can handle missing mailer and do something useful in that case, I think I will switch the RPM dependency on postfix to just Recommends and not Requires. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
