On 4/10/2019 4:10 AM, Brian (bex) Exelbierd wrote:
On Tue, Apr 9, 2019 at 8:40 PM Japheth Cleaver <cleaver@xxxxxxxxxxxxxx> wrote:
Is this really worth the effort? cronie in F30 is a 103K package, and a
decent chunk of that might be the ChangeLog. crontabs is all of 18K,
which is 95% the GPL and the RPM header. It seems like a very small
price to pay for something everyone is going to assume will be on any
*nix-compatible system of note.
I read, possibly misread, the original comment as being about the
number of "unneeded" things in the install, not necessarily the weight
of the specific packages. What I think we are hearing from
containers, OSTree, etc. is that there is a group of people that wants
their systems more minimal with less unnecessary stuff.
*snip*
This seems to go back to who is the primary target audience for our
Workstation edition and what do they want/expect. Then we can
document the changes and socialize them over a few releases so that
other users can get to where they want to be. Basically "extra" isn't
what no one wants, its what our defined target doesn't want/expect.
Although this was originally posted about Workstation, I can virtually
guarantee that a solution accepted for implementation would not be
"Remove cron in %post," thus this really comes about as removing it as a
default install pretty much everywhere. Of course, things like
OSTree/atomic, containers, and micro-environments where every byte
counts are likely to be bypassing typical installation mechanisms
regardless to fine-tune what's delivered -- eg, removing documentation,
etc in docker kickstart %post, or re-implementing parts of RPM to begin
with.
Reducing the Minimal size is, in general, good, but it's possible to go
too far, and I think that's the case with low-level, *nix wide tools
like this. I'm reminded of the time someone thought tar needed to go
too: https://bugzilla.redhat.com/show_bug.cgi?id=1409920
One might make the case for a removal from @core -- *maybe* -- but
definitely not @base.
Lastly, taking a position on some of this, for example, removing cron,
is a form of opinionation that calls back to our roots of innovating
in the OS space. We would be saying, we recognize this is the way we
did things X years ago, but there are new ways and processes and we
see value in those. If we can't remove these things, then we are
being a good distribution by pointing out where solutions that claim
to fix something have fallen short so that those upstreams can make
decisions about what to do.
But what, exactly, has cron fallen short in? I'm reminded of that old
testimonial tag line for the similarly named, but unrelated, utility
cronolog: "cronolog kicks ass in every conceivable way in which a
utility like cronolog can kick ass." (
http://web.archive.org/web/20090627031834/http://cronolog.org/ ) There
are other launching mechanisms, sure... I've worked on one of them, but
that doesn't mean there's anything wrong with cron, or /etc/cron.*/
directories.
More directly, I'm old enough to remember when we were assured that
systemd's timers were not "to be in competition here" with cron, and and
it was promised to "make sure that cron is advertised as a good solution
for people who just want to queue a simple cronjob." With all the
discussion of ease-of-use and discoverability, removing the "good
solution" mechanism for users in favor of something requiring a package
install doesn't seem to be a great example of that.
https://lists.fedoraproject.org/pipermail/devel/2014-March/196293.html
The last thing I'd want to have to deal with is solving for a missing
/etc/cron.* because someone forgot to click a checkbox somewhere or
didn't call it out in kickstart.
Yes, but I also don't want to deal with a security fix in cron when I
didn't want it to begin with. Adding software the user doesn't want
to have it as assumed for other users is always a trade-off.
True, but - as written elsewhere - that can be taken to a logical
extreme, both via removal of simple, auditable utilities and shell
scripts, and eventual giant replacements.
-jc
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
