On Thu, Aug 06, 2009 at 03:21:41PM -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; > > 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. No, I did not state that, but maybe it was not obvious. I stated that the groups should be put together. I agree that the "IT security" is not needed in the password tools description and that the typo should be fixed, it the term is used. I fail to understand why you think they are not strongly related, they existence of the security spin proves that they are imho. I considered IT might be redundant information, too, when I created the groups, but also both the terms "Forensics" or "Wireless" are not IT specific, therefore I put the IT-security explanation into the description. There can be wireless analysis that is not security related, e.g. to find sources of disturbance and there are a lot of forensics tasks that are not IT-security related, but still could be assisted via software. But I do not care that much to keep the term in the description, this was just my motivation to put it there. > > > > 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. This is no solution to grouping the packages together and still be able to know which packages are for which sub group of tasks. Btw. these tools to also not build a base system or at least what I would think of a base system, because their use case is for certain special tasks and does not form a base for other tools to build on, e.g. cron performs a base set of features that can be used by other packages. But this might not the criteria for packages in the base system category. > > > > > 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' I am impressed, I believe to have worse search experiences with yum search. Nevertheless, airsnort is missing there, but on the other hand kismet-extras is maybe missing in comps. But I do not currently know whether or not comps is subpackage aware. > My objections are: > - the use of a toplevel category (they should be under the existing > categories) This is addressed in my new proposal, they would be in no category or can be in any existing category. > - the excessive use of IT-security most everywhere, when it's not needed I'm fine with removing it from the description, but I would like to keep this or only security as a common prefix. > - 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.) There are smaller groups currently in comps and the amount of packages per group is not final, e.g. I already identified more packages that would go into the wireless group and I already did not create a anonymity group, which is used on the security live cd webpage, but would only have two packages, that I know I would add to it. > - the 'all packages are default' paradigm I could accept to make packages not default that are e.g. already meant to be deprecated by upstream, like airsnort. But I do not think that the audience of these tools would only want to be presented some random password cracker like it is a guideline to have only one IM client on the Fedora Desktop live image. This is also reflected with the package set of the security live image, which also contains all these tools and not only selected ones. Regards Till
Attachment:
pgp3SmCWaKiIM.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
