Re: [hackers] [ubase] [PATCH] install: ignore -s

From: Mattias Andrée <maandree_AT_kth.se>
Date: Tue, 27 Dec 2016 16:25:09 +0100

On Tue, 27 Dec 2016 13:56:07 +0100
Laslo Hunhold <dev_AT_frign.de> wrote:

> On Sat, 3 Dec 2016 12:51:14 +0100
> Mattias Andrée <maandree_AT_kth.se> wrote:
>
> Hey Mattias,
>
> > The -s flag previously called strip(1) on the installed
> > file. This patch changes install(1)'s behaviour to
> > ignore -s.
> >
> > Many makefiles use the -s flag, so it has to be
> > recognised for compatibility, however it does not have
> > to do anything because symbols do not negatively affect
> > the functionallity of binaries.
> >
> > Ignoring -s have the added benefit that the user do not
> > need to edit makefiles if they want the symbols that
> > are useful for debugging. If the user wants to strip
> > away symbols, it can be done manually or automatically
> > by the package manager.
>
> thanks, applied! I favor just not documenting the s-flag
> in xinstall.1, but understand both sides of the argument.
> We have many examples in sbase, like sort -m, but also as
> we can see install -c and others.
>
> Maybe we can discuss this here. Another alternative would
> be to put that in a NOTES section. I really don't want to
> see the manpages filled up with ignored options, making
> them harder to read. On the other hand, a manpage should
> reflect the code and no matter how we put it, we do
> handle the c and s flags specially here.
>
> Cheers
>
> Laslo
>

What about adding an IGNORED OPTIONS section after OPTIONS,
where it is stated what the ignored options were intended
to do, and perhaps a rationale for why it is ignored? This
way users can be sure that it is safe to use a flag and
that we will not add a behaviour to it in the future that
they did not foresee.

Received on Tue Dec 27 2016 - 16:25:09 CET

This archive was generated by hypermail 2.3.0 : Tue Dec 27 2016 - 16:36:16 CET