On Thu, Aug 06, 2009 at 01:24:24PM -0400, Bill Nottingham wrote: > 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; 3) The description will be translated / meant to be human readable and not to be a machine readible property. > > 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. > > 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. > > > 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. > > > Moreover, what's the usage case in that you really need all three > > > tools (which is the default if you install the group you mentioned)? > > > > Everyone on a multi user system can use the tool of his preference. > > ... > > 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? > > Also > > there may be a feature in one application, that is missing in another. > > Then fix one app so that it's reasonable enough. To quote Adam Jackson: In reality, one does not very often have the time to first fix a bug, before a task can be completed. So this does not help me right now if I need to perform a task. Nevertheles the fixing can still be done later. > "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. > In comps, in most any group, the default item is the best-of-breed app; > other implementations are optional. I see, comps is not the right place to implement the feature that fulfills my need. > > Btw. I fail to understand what trouble this is causing you. Thanks to > > bundling all together into one category, it will even disturb you less > > than six (or more) groups in some other category, where the stuff you > > are interested is. > > It's about not presenting bad UI and bad groups to our users - it's > a design thing. 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. In conclusion I have reverted the IT-security related changes to the comps-f12.xml.in file. Regards Till
Attachment:
pgpVQnLmGCuUt.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
