Needs new category/file: Reverse Engineering Software

Needs new category/file: Reverse Engineering Software

[Nils Gillmann]

I see nothing in gnu/packages/ where I could put reverse
engineering, disassembler tools.
What I want to package is the disassember panopticon
(https://panopticon.re)

Existing:
code.scm is a bit too generic for the specific purpose of panopticon
debug.scm does not get the category right.

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.

Additional thoughts:
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.
Other solution: use the new category only for software
specifically developed for RE.

What do you think?
-- 
ng

Re: Needs new category/file: Reverse Engineering Software

[Andreas Enge]

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.

> 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.

Andreas

Re: Needs new category/file: Reverse Engineering Software

[Nils Gillmann]

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

Package modules

[Fabian Harfert]

Hi!

I don't understand the point that makes package modules necessary in
general and theoretically. We can have each package only once, so
there's no need for that.

I know that practically it is necessary because it's easy to structure
and results from the definition of packages like program code.

But why isn't it possible to include all the packages modules from (gnu
packages) automatically? Is there something speaking against that?

Fabian

Re: Needs new category/file: Reverse Engineering Software

[Andreas Enge]

On Thu, Feb 18, 2016 at 03:33:23PM +0100, Nils Gillmann wrote:
> 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?

Well, this is a big mess in Guix, between modules for a single package
(many of which dating back to when we started) up to python.scm containing
everything python. Both are fine I think, feel free to make a choice!

Andreas

Re: Package modules

[Ludovic Courtès]

Fabian Harfert <fhmgufs@web.de> skribis:

> I don't understand the point that makes package modules necessary in
> general and theoretically. We can have each package only once, so
> there's no need for that.
>
> I know that practically it is necessary because it's easy to structure
> and results from the definition of packages like program code.

Right.  The thing to keep in mind is that “package modules” are just
regular Scheme modules/libraries that export variables and import other
modules.

The advantage is that we get the semantics and all the functionality of
Guile’s module system.  The downside (the one you had in mind I guess?)
is the boilerplate in each file.

I think the advantages outweigh the disadvantages, though it would be
cool if Guile supported a Racket-style #lang construct to help reduce
boilerplate.

> But why isn't it possible to include all the packages modules from (gnu
> packages) automatically? Is there something speaking against that?

Yes.  For one, having control over which modules are imported allow you
to make sure there are no name clashes, no ambiguities, and such.

Thanks,
Ludo’.