From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Jan Kara <jack@suse.cz>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Lukas Czerner <lczerner@redhat.com>,
linux-ext4@vger.kernel.org, Jan Kara <jack@suse.com>
Subject: Re: How to package e2scrub
Date: Fri, 31 May 2019 08:43:30 -0700 [thread overview]
Message-ID: <20190531154330.GA5378@magnolia> (raw)
In-Reply-To: <20190531100713.GA14773@quack2.suse.cz>
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.
All good reasons for a separate package, particularly considering that
on the RH side they've split out xfs_scrub because of its python 3
dependencies.
> > Out of curiosity, were any of the complaints that you've heard gone
> > beyond people who ran into the various e2scrub/e2scrub_all bugs? I'm
> > curious what their concerns were.
>
> I didn't hear any complaints so far. But I have my doubts anyone actually
> run that code so far - openSUSE Tumbleweed has limited userbase, we do
> installs to btrfs by default, we don't propose LVM by default, and I didn't
> enable the service files to run by default.
(I suspect it's only Debian Unstable users who are running it right
now...)
--D
>
> Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
next prev parent reply other threads:[~2019-05-31 15:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 12:06 How to package e2scrub Lukas Czerner
2019-05-29 18:21 ` Darrick J. Wong
2019-05-29 18:34 ` Eric Sandeen
2019-05-30 6:04 ` Christoph Hellwig
2019-05-30 15:28 ` Darrick J. Wong
2019-06-03 11:19 ` Emmanuel Florac
2019-06-03 12:39 ` Lukas Czerner
2019-05-29 23:59 ` Theodore Ts'o
2019-05-30 1:54 ` Andreas Dilger
2019-05-30 9:59 ` Jan Kara
2019-05-30 13:51 ` Theodore Ts'o
2019-05-31 10:07 ` Jan Kara
2019-05-31 14:10 ` Theodore Ts'o
2019-05-31 21:43 ` Andreas Dilger
2019-06-03 9:30 ` Jan Kara
2019-05-31 15:43 ` Darrick J. Wong [this message]
2019-06-03 12:32 ` Lukas Czerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190531154330.GA5378@magnolia \
--to=darrick.wong@oracle.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.