[pacman-dev] [PATCH] Have configure set pactest options that it knows.
allan at archlinux.org
Sat Dec 28 01:04:59 EST 2013
On 28/12/13 15:21, Jeremy Heiner wrote:
> Allan McRae <allan at archlinux.org> wrote:
>> What I do not like is that your patch is taking away options. It would
>> have been less work to leave in support for those flags than to remove
> Taking away options is what software engineering is all about. Module.
> Class. Encapsulation. API. Any script kiddy can barf up a mess that
> can (sorta) get it done. Is that really the direction you want to
> steer this project in?
> I don't care how much less work it would have been to leave those
> unmentionables unmentioned. Burying dirty laundry never results in
> clean linen.
Your patch keeps the flag to allow us to use the system pacman but not
the flag to allow us to set its scriptlet shell if it is different from
the pacman in the build directory. So to actually use a system pacman
with a different scriptlet shell will now require a separate build
directory configured with the appropriate shell. That is completely
Taking away a the --scriptlet-shell option and in the process making the
-p potentially require a non-obvious process to provide an appropriate
shell seems a poor decision to me.
>> Yes... lets pretend I have looked at those patches... :)
> That is my whole point! You spent too much time looking at the patches
> I submitted. I thought: "obviously he's using the autoconf tools so
> this patch won't take up much of his time".
I have not even applied the patches yet, so time is not spent
(re)building. Actually building with a patch applied should be the most
minor part of reviewing a patch.
> But I was apparently
> wrong. I apologize. Yet when I suggest using decades-old tools to
> alleviate the problem the response is "no thanks." Odd.
There was no problem. This is still no problem if I do not push a patch
removing an option from pactest.
I will not spend more time replying to this thread. Patch rejected by
me unless the --scriptlet-shell options is kept in pactest.py.
Alternatively, there needs to be a community consensus that this is the
right thing to do, in which case my decision gets overridden.
More information about the pacman-dev