Till Maas (opensource@xxxxxxxxx) said: > 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. Rather than going back and forth about concepts, I might as well just describe how I would organize what you have now: network-debugging - Network Analysis Tools - Tools for analyzing and securing computer networks. (This would include the packages from both your proposed 'reconnaissance' and 'wireless' groups, as well as some other tools currently in 'System Tools'.) forensics - Computer Forensic Tools - Tools for performing computer forensics and data recovery. (I'd move the password tools here, as well. Not sure how clamav fits here; I think its current placement at the mail server level makes more sense.) The intrusion detection group looks OK as a concept. As for the code analysis group, I'd argue that should be moved into the development category. Is this something you'd find usable? > > 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. Right now our toplevel groups are: - Language support (self explanatory) - Desktops (fairly self explanatory) - Applications (End-user desktop applications) - Development (tools for software development) - Servers (various system services) - Base system (administration tools, and other components) Perhaps a better solution is a new toplevel category of 'System Administration' (where most of your new groups would fall under); this widens the scope of it from just 'IT Security' to a larger scope that fits the existing categories. That might be a larger reorganization, though, as the group changes would have to filter down to the various spins. > > - 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. Sure, but the live spin can do %group --optional to pull those in. To expand on what I said before, we have three main concepts for applying defaults in comps: - Lots of tools that occupy the same usage case (office tools, etc.) Pick one best-of-breed default, the rest are optional. - Lots of tools that occupy the same space, but are not interchangable. (games) Everything's optional. Pick what you want. - A basic usage case, with various add-ons and similar tools. (many of the server groups, 'system tools', etc.) A base set that's default; other tools are optional. Bill -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
