Re: Needs new category/file: Reverse Engineering Software

[Nils Gillmann <niasterisk@grrlz.net>]

Andreas Enge <andreas@enge.fr> writes:

> Hi Nils,
>
> On Wed, Feb 17, 2016 at 03:38:42PM +0100, Nils Gillmann wrote:
>> 
>> As this doesn't do the job for me, I propose
>> gnu/packages/disassembler.scm
>> or
>> gnu/packages/re.scm
>> or
>> gnu/packages/reverse-engineering.scm
>> as it specifies an existing category of software and is not just
>> another debugger.
>
> the first and the last of these are fine; I would avoid "re" as it is not
> a word, and it is not clear at all what it is supposed to represent.

Okay, understood. However, there's now the choice between a
specific category (disassembler.scm) and a meta category
(reverse-engineering.scm).
Not having read every single line of the source of Guix yet, are
meta-categories in general more welcome than specific categories?

Reasons for meta would be that it's not limited to a specific
category and serves more than one purpose. However, it will also
be up to individuals to decide wether this is software typically
used in the context of the name of the meta category. This might
lead to further irritation for beginners. disassember.scm would
give the specific instruction "put disassembler software inside
me".

I have not counted the number of debugging software, disassembler
software, hex focused editors, PE and resource viewers in Guix
sources. It might lead to a rather long file which centers on
this topic.

If I start disassembler.scm it has a one purpose, specific
intention to just get disassemblers inside.
If I start reverse-engineering.scm, it is open to moving specific
sets of software inside.

What are your thoughts on this?

>> Reverse engineering typically makes use of Debuggers,
>> Disassemblers, Hex Editors and PE and Resource Viewers. A
>> new category could be used to cut down on category files maybe
>> get some existing, non-specific software into the new created
>> category.
>
> Do I understand correctly that you wish to move existing software into
> the new module (=file)? Why not if you do the work :-)
> Moving packages around is somewhat boring work and needs to be done
> carefully, since all the "use-module" clauses in files where the package
> is used need to be adapted.
>

See above, specifically last paragraphs.

> Andreas
>

-- 
ng