Bug 894110 - The "standard" comps group could use a bit of spring cleaning
Summary: The "standard" comps group could use a bit of spring cleaning
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: comps
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Václav Pavlín
QA Contact:
URL:
Whiteboard: RejectedFreezeException
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-10 18:15 UTC by Lennart Poettering
Modified: 2016-04-04 13:10 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-27 01:32:56 UTC
Type: Bug


Attachments (Terms of Use)

Description Lennart Poettering 2013-01-10 18:15:16 UTC
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.

Comment 1 Sandro Mathys 2013-01-10 18:40:51 UTC
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.

Comment 2 Kevin Fenzi 2013-01-10 22:10:51 UTC
I'm fine with dropping all the stuff in comment 0. 

Additional discussion on list about other items in nottings list.

Comment 3 Tomas Mraz 2013-01-11 17:50:49 UTC
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.

Comment 4 Kevin Fenzi 2013-01-11 18:57:36 UTC
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.

Comment 5 Tomas Mraz 2013-01-12 00:41:24 UTC
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.

Comment 6 Adam Williamson 2013-03-07 23:12:08 UTC
-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.

Comment 7 Adam Williamson 2013-03-07 23:13:03 UTC
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.

Comment 8 Adam Williamson 2013-03-27 18:05:06 UTC
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.

Comment 9 Fedora End Of Life 2013-04-03 16:33:24 UTC
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

Comment 11 Matthew Miller 2014-03-24 19:01:41 UTC
Phil, can we get this on the agenda for the Base Design Working Group? Thanks.

Comment 12 Stephen Gallagher 2015-03-12 21:04:00 UTC
Can we get a status update on this?

Comment 13 Jan Kurik 2015-07-15 14:53:28 UTC
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

Comment 14 Zbigniew Jędrzejewski-Szmek 2016-01-27 01:32:56 UTC
Done now for F24.

I only left pinfo/info, because I wasn't sure which one to drop.

Comment 15 Alvaro Kuolas 2016-04-03 14:29:42 UTC
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/

Comment 16 Adam Williamson 2016-04-03 18:21:16 UTC
I don't think that would be appropriate for 'minimal'. it's more arguable for 'standard'.

Comment 17 Alvaro Kuolas 2016-04-04 12:52:26 UTC
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.

Comment 18 Stephen Gallagher 2016-04-04 13:10:36 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.