Re: Can we maybe reduce the set of packages we install by default a bit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux