Till Maas (opensource@xxxxxxxxx) said: > > > The IT prefix is only used in the group id, which is afaik not visible > > > to the used and not translated. > > > > No, it's not just in the description. > > > > "These tools can be used to perform IT security related wireless auditing." > > > > In this example, "IT security related" (aside from missing a hyphen > > or two) is completely superfluous. > > 1) It is not a prefix in the description > 2) It does not allow easy selection of the packages, which was the > feature you said that it allows to have and which is the necessary > context you removed: > > | I'm not sure they need to be bundled. Especially with 'IT' as a > | prefix; Sorry, I should have expanded. It's bad to use the acronym at all. > > > I don't understand what you want to say > > > with "password recovery" is "password recovery". There is nothing to > > > argue about, but nevertheles the groups are related to each other, > > > > How so? aide is not really related to password recovery at all, > > at least not in any generally describable way. > > So the assignement of tools to the groups can be improved. Does this > make the groups useless? I say no, there I don't see how this does > belong to this general discussion about whether or not there should be > these groups in comps. You're stating that IT should be in the description as the groups are 'related'. I don't see how they're really that strongly related at all, and IT is superfluous information to the use case. > > > already expresses itself that they are all on the security spin. Also it > > > allows other people to easier ignore them, instead of cluttering other > > > categories. > > > > Put it this way: > > > > - These packages are all in other groups under 'Base System' > > - Ergo, if they're being grouped together, the resulting group > > should still be under 'Base System' > > It is not technically possible to have subgroups, as you can see in the > answer from Jesse Keating. Additional groups under Base System, not sub-sub-groups. > > > > Tagging would help with this; as it stands now, 'yum search wireless' > > > > or 'yum search wireless sniffer' would return the packages in your > > > > wireless group. > > > > > > Probably, but this cannot be done right now afaik. > > > > yum search certainly can be done now. > > Yes, but is there an easy search expression that will result with the > groups that I added? Afaik no. Does 'yum search wireless' returns 43 > lines of packages, so it does not qualify. # yum search wireless sniffer Loaded plugins: refresh-packagekit, verify ============================== Matched: sniffer, wireless ============================== aircrack-ng.x86_64 : 802.11 (wireless) sniffer and WEP/WPA-PSK key cracker kismet.x86_64 : WLAN detector, sniffer and IDS kismet-extras.x86_64 : Non-core programs for 'kismet' =================================== Matched: sniffer =================================== driftnet.x86_64 : Network image sniffer ... > > So, the goal of this is for a multi-user forensic system, where > > you have multiple users working on the same system su-ing to root > > and running the tools of their choice? That's an odd usage case > > to design for by default. > > Afaics I did not mention the forensics group. I can't answer your > questions if you refer to different groups with "the group" and then > argue against the answer using some other group. The forensics group had > 15 packages in it if I counted correclty and e.g. pdfresurect and > chkrootkit are completely different applications. But how does searching > for good or bad examples help here? Sorry, should have more clearly mentioned I was using the wireless tool as an example. > > "Choice is not the goal. We have many interesting problems to solve and > > forcing the user to care about their choice of solutions is both bad UI > > and actively detracts from the real goal, which is making it work out > > of the box and enabling people to work on the really cool stuff at the > > edges." > > I do not know users who prefer to wait several days to months to perform > a task with one application instead of doing it with another > application. Especially not if the need to perform the task right now. ... what I'm saying is how this should be presented. I'm sure there are features that are only in OpenOffice.org that someone may need, and features that are only in KOffice, and features that are only in abiword/gnumerif/etc. But when we're selecting a default set of packages to install for 'Office Suite', we only install one. And we'd prefer that we fix things to where we only need one in the long term. > I do not agree that my groups are bad or that they are bad by their > nature. Nevertheless, I do not see that this discussion is leading > anywhere, that will allow to fulfill my needs (Easy installation of the > software, easy finding of the software, allowing many people to do this > and not maintaining the same information in several places) and your > requests. Also it looks for me that you do not want these groups at any > cost, because of the way you argue. My objections are: - the use of a toplevel category (they should be under the existing categories) - the excessive use of IT-security most everywhere, when it's not needed - the potential explosion of small groups (long term, we need to make tagging and searching work. Splitting into groups for every small usage case doesn't scale.) - the 'all packages are default' paradigm Bill -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
