Re: How to package e2scrub

Re: How to package e2scrub

[Darrick J. Wong]

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.

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.

--D

> Thoughts ?
> 
> Thanks!
> -Lukas

Re: How to package e2scrub

[Eric Sandeen]

On 5/29/19 1:21 PM, 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".

Yes it is a bit clunky but *shrug*

The main motivator for this was one piece uses python3 and that Made People
Sad who wanted minimal systems with minimal deps but still wanted xfsprogs.

Keeping services separate is a good idea as well, I think.

I don't have a strong opinion on whether /just/ the service should be separate,
or the scrub util + the service should be separate.

I put all the xfs scrubbing bits in one package in rawhide.

-Eric

Re: How to package e2scrub

[Christoph Hellwig]

On Wed, May 29, 2019 at 11:21:11AM -0700, Darrick J. Wong wrote:
> Indeed.  Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find
> that name to be very clunky and would have preferred "xfs_scrub".

Why not just xfs-scrub?

Re: How to package e2scrub

[Darrick J. Wong]

On Wed, May 29, 2019 at 11:04:26PM -0700, Christoph Hellwig wrote:
> On Wed, May 29, 2019 at 11:21:11AM -0700, Darrick J. Wong wrote:
> > Indeed.  Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find
> > that name to be very clunky and would have preferred "xfs_scrub".
> 
> Why not just xfs-scrub?

Slight preference for the package sharing a name with its key
ingredient:

# xfs_scrub /home
Bad command or file name
# apt install xfs_scrub
<stuff>
# xfs_scrub /home
WARNING: ALL DATA ON NON-REMOVABLE DISK
DRIVE C: WILL BE LOST!
Proceed with Format (Y/N)?

--D

Re: How to package e2scrub

[Emmanuel Florac]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

Le Thu, 30 May 2019 08:28:55 -0700
"Darrick J. Wong" <darrick.wong@oracle.com> écrivait:

> On Wed, May 29, 2019 at 11:04:26PM -0700, Christoph Hellwig wrote:
> > On Wed, May 29, 2019 at 11:21:11AM -0700, Darrick J. Wong wrote:  
> > > Indeed.  Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I
> > > find that name to be very clunky and would have preferred
> > > "xfs_scrub".  
> > 
> > Why not just xfs-scrub?  
> 
> Slight preference for the package sharing a name with its key
> ingredient:
> 
> # xfs_scrub /home
> Bad command or file name
> # apt install xfs_scrub
> <stuff>
> # xfs_scrub /home
> WARNING: ALL DATA ON NON-REMOVABLE DISK
> DRIVE C: WILL BE LOST!
> Proceed with Format (Y/N)?
> 
> --D

Debian packages always replace _ with - in the package name itself
because the _ is used to separate the package name proper from the
version and architecture : package_version_arch.deb.

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: How to package e2scrub

[Lukas Czerner]

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