We shouldn't install that much stuff in the standard install. Here's a list of what I'd suggest to remove: ntsysv tmpwatch (nothing needs this and tmpfiles does this anyway, and this is really something that should never have been in comps but should have been pulled in by deps) bridge-utils dump finger iptstate irda-utils lftp (either this or ftp should go, but we don't need both installed) numactl pcmciautils pinfo (either this or info should go, but we don't need both installed) pm-utils (superseded by systemctl suspend and friends, and is a bit too low level to have around by default since it ignores inhibitors and stuff) rdate rdist rsh stunnel talk Some of these probably have their fans (see fedora-devel), but these are those I at least would like to see gone.
A fix for this issue seems long due even when the details might require additional discussion. While this matches no release criteria but can't be fixed with an update, I propose this as a "nice to have" (NTH) for Fedora 19. Blocking F19Alpha-accepted to have it considered (and fixed) ASAP but technically fixing it in Final would be fair enough.
I'm fine with dropping all the stuff in comment 0. Additional discussion on list about other items in nottings list.
What is the definition of "standard" comps group? For example I don't think stunnel is obsolete at all. And in case of (l)ftp a (p)info I'd certainly vote for dropping ftp and info as they are much less useful.
Well, I guess it might be nice to have a "definition", but not sure how exacting we can be. - Utilities that will be installed on (most) Fedora installs. - Are generally useful for troubleshooting to allow network/yum to work. - Allow admins to read local docs From the description: "Common set of utilities that extend the minimal installation" So, I would say we should be dropping things that are no longer 'common' or that we feel are needed on (many) Fedora installs. For stunnel, is that something you need on a new install before you 'yum install stunnel' ? ie, is there a great advantage in having it local or always known to be installed? We can't easily drop info since it currently owns /usr/share/info/dir which I think other things need. I guess we could keep pinfo, I don't care.
I think that FESCo (or someone else but who) should first agree upon the definition of the comps group and then we will be able to properly remove/add stuff to it. I mostly agree with your definition above. And that would imply to drop stunnel, _probably_ keep pinfo, and keep some ftp client - where I'd vote for lftp. I know that curl can pull files from ftp, but it is not an interactive ftp client. Anyway is the size of standard comps group a real problem? I am all for dropping clearly obsolete stuff from it but it should not be a problem to keep things that are controversial.
-1 freeze exception: this is exactly the kind of thing we *should* get done before freeze and should *not* start poking once we're trying to get a release out.
Note for Sandro: "to have it considered (and fixed) ASAP" - this is not what the blocker / FE process is really for. It's not a 'todo' list or an 'urgent' list. Please try to avoid using it this way.
Discussed at 2013-03-13 FE review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-13/f19alpha-blocker-review-1.2013-03-13-17.02.html . Rejected as a FE per comment #7, this is not an appropriate change for a freeze period.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Phil, can we get this on the agenda for the Base Design Working Group? Thanks.
Can we get a status update on this?
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Done now for F24. I only left pinfo/info, because I wasn't sure which one to drop.
I believe that wpa_suplicant and NetworkManager-wifi should be included in Standard or Minimum comps group. I am facing this issue right now: https://ask.fedoraproject.org/en/question/64217/how-to-connect-to-wifi-using-nmcli/
I don't think that would be appropriate for 'minimal'. it's more arguable for 'standard'.
It depends, because Ethernet is a first class citizen, but WiFi it is not. Right now there are computers with only WiFi and no Ethernet (laptops, NUCs, Chromebox, etc). But the inclusion in standard it is sound to me.
(In reply to Alvaro Kuolas from comment #17) > It depends, because Ethernet is a first class citizen, but WiFi it is not. > > Right now there are computers with only WiFi and no Ethernet (laptops, NUCs, > Chromebox, etc). > > But the inclusion in standard it is sound to me. Sure, but if you're actually building a "minimal" system, the likelihood that it will have wifi but not ethernet is vanishingly small. (NUCs and streaming sticks being the exception). More likely, if you are trying to construct an OS from a minimal install, it's because you are building a server or appliance device that will be wired in. So I agree that it absolutely doesn't belong in @core. As for @standard, it gets a little bit more fuzzy. This is kind of why we have new Editions in Fedora now. In a "standard" installation of Fedora Workstation, having WiFI work is probably a critical necessity. However, a "standard" installation of Fedora Server or Fedora Cloud is unlikely to need it. I'm personally of a mind that the @standard group should be entirely retired in favor of a series of functional groups that the various editions and spins would pull in. Which sounds a lot like... modules. @standard (and @core) have a lot of history built primarily around the idea that there was *one* Fedora deliverable and so those two groups attempted to accommodate everyone (succeeding at accommodating essentially no one). It's time they were retired.