Re: Bug#224742: Related to this issue...
On Sat, Dec 27, 2003 at 12:00:33PM +1000, Anthony Towns wrote:
> > Again, I think the way it actually works should be changed, and I think
> > it's useful for this *technical* considerations of mine to be held in
> > the records.
> There aren't any technical considerations: " test-foo yes" has all
> the same properties as would "test-foo", with the added benefit that it
> works right now. You happen not to like that. Good for you.
There are IMHO. To resume them:
1) Parameterless lines can be useful when a parameter made no sense
(and I gave you an example of such a case)
2) I added that I would like ifupdown to stop enforcing not to have
repeated lines, with an example of when such a case would be useful
3) I repeatedly asked for technical reasons why you didn't want to
change ifupdown accordingly, and I was ready to discuss them, and
maybe accept them, but you never provided any
4) I showed you examples of other programs accessing
/etc/network/interfaces and proposed considering a wider role for it
You instead answered me suggesting a way to change guessnet instead,
a way which I thought is not good either (with explanation).
Then the discussion went on "should this issue be closed or not" in
which we got to no agreement between us and in which I tried to consult
debian-devel in order to know how this issue should be handled, which I
think it was reasonable. You didn't.
> Mmm. Do you have any plans to review the way _you_ handled this case?
I would have handled it differently, having received more cooperation
from you. For example, I've been made aware (by other people) that
unrecognized parameters are passed as environment variables to scripts.
Given this, it is not obvious how to map repeated or parameterless lines
to env vars. I would have liked to have discussed about this.
For the records, a proposed way to handle this could be:
1) Have ifupdown add a "1" or similar value to parameterless lines when
building the environment for scripts
2) Newline-concatenate the parameters of repeated lines
With the benefit of having this nice possibility of splitting long
lists in more lines:
iface foo inet static
[...]
features apache firewall php proxy home
features ftp-server nfs-exports
With a script doing something like:
for i in $features
do
case "$i" in
apache)
[...]
[...]
esac
done
On Sat, Dec 27, 2003 at 11:56:27AM +1000, Anthony Towns wrote:
> > Who's acting obnoxiously and insisting to speak of a feature *request*
> > as if it was a *demand*?
> I give up, who is?
> ] > test-missing-cable really needs no arguments. However, ifupdown chokes
> ] > on it:
> ] Yes, that's correct. Use:
> ] test-missing-cable yes
> ] instead.
> was my first response. It got more blunt when the reply to that was:
> ] That'd be stupid: as "test-missing-cable no" would be nonsense, it's
> ] crazy to ask the user to put "yes" there. I've solved removing the '-'
> ] after "test" on all directives, instead, which makes more sense.
That's my response to you requesting a feature change in guessnet
instead (without again telling me why you didn't want to change
ifupdown). In which I showed how I didn't think the change you proposed
was right, and I added how instead I planned to act in the direction you
indicated me.
(which plan was again wrong because of the other ifupdown enforcement I
later reported, and which was pointed to me by other people and not by
you)
> Filing a bug isn't an attack. Repeatedly reopening a bug is. Repetedly
> reassigning a bug is too. Repeatedly filing new bugs is as well.
Could repeatedly closing one giving no explanations when requested be
considered an attack, too?
> If you have some feature you want added that the package maintainer
> doesn't think is desirable, you either persuade him/her to change his/her
> mind, learn to live without it, or if it's important enough you take
> the issue up with the technical committee.
You can't say that I didn't try to start a discussion with you in order
to change your or my mind.
> > So - proof by authority?
> It was a serious question: I obviously have more experience here than
> Enrico; what exactly makes you think he's right and I'm not? You know
> the saying, "the race isn't always to the swift, but that's the way to
> bet" right?
What exactly makes you think you are right and I am not, either? Age?
Experience? Old maintainers are always right?
I wasn't sure to be right in reopening the bug, and I asked debian-devel
about that. Did you wait for an answer?
(I hope these clarifications can help a bit both sides understand each
other in this issue)
Ciao,
Enrico
Reply to: