That file may be available online for this particular software. The
debate is about whether such configure.ac file must be included in the distributed package for making the package dfsg. And more in general,
about where to draw the line on how easily editable (think: time well
spent) the included source code must be for making the package dfsg. In
my opinion there is no sharp line, and ftpmaster is well positioned for making fair choices in a +/- uniform way for all packages. And there is always be room for questioning those choices and allowing the meaning of
dfsg evolve over time. Back to configure.ac, I'd support a choice of
making a missing configure.ac an 'important' bug, and not enough for rejecting the package as non-dfsg.
Bart Martens <bartm@debian.org> writes:
That file may be available online for this particular software. The
debate is about whether such configure.ac file must be included in the distributed package for making the package dfsg. And more in general,
about where to draw the line on how easily editable (think: time well spent) the included source code must be for making the package dfsg. In
my opinion there is no sharp line, and ftpmaster is well positioned for making fair choices in a +/- uniform way for all packages. And there is always be room for questioning those choices and allowing the meaning of dfsg evolve over time. Back to configure.ac, I'd support a choice of
making a missing configure.ac an 'important' bug, and not enough for rejecting the package as non-dfsg.
The general rule of thumb that I've followed in similar situations in the past (PDF files where the original source has been completely lost, for example) is that the underlying purpose of the DFSG source provision and
of free software in general is to ensure that the recipient of the
software is not at a disadvantage. In other words, the distributor isn't allowed to hold back pieces that make it harder for the recipient to
modify the software (within the general definition of "source," of
course).
Therefore, it matters what the distributor has. If they have the true
source used to generate the file but are keeping it secret, then to me
that's a violation of the DFSG and we shouldn't participate (even if their actions aren't technically a violation of the license since if they own
the copyright they don't need a license). This is creating that
disadvantage for the recipient that free software is designed to prevent.
But if the original source has been lost, then everyone is on an equal footing, and I don't think there's a DFSG violation. We may not have the true source in the intended sense, but *no one* has the source, and
therefore everyone is on an equal footing and has equal ability to modify
the software.
There is a different wrinkle in this specific case: we may have the source but not the software that was used to generate the file from the source.
In this case, it sounds like an old version of Autoconf was used, and we don't package that version of Autoconf any more, so while the source is present in one sense, one can't regenerate the file. I'm not sure the
DFSG is the most useful framework for analyzing that situation, since to
me it feels more practical than freedom-based. Everyone is still in basically the same situation: the source is available to everyone, but
some work may be required to go hunt up the old tool and regenerate the
file. (This assumes a case like Autoconf where the old releases of the
tool are readily available and not kept secret, but may be hard to get working.)
The real problem in this case is less about the DFSG and more about the practical problems of maintaining Debian as a software distribution: if we can't regenerate configure using software in Debian, there are a lot of porting tasks and some bug-fixing tasks that we can't do, and that's a problem for us. But I'm dubious that it's a *software freedom* problem;
it's more of a *software maintenance* problem, and thus the bug severity should be based on how much of a problem that is in practice.
(I think this is mostly a long-winded way of saying the same thing Marco said.)
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Bart Martens <bartm@debian.org> writes:
That file may be available online for this particular software.
The debate is about whether such configure.ac file must be included
in the distributed package for making the package dfsg. And more in
general, about where to draw the line on how easily editable
(think: time well spent) the included source code must be for
making the package dfsg. In my opinion there is no sharp line, and
ftpmaster is well positioned for making fair choices in a +/-
uniform way for all packages. And there is always be room for
questioning those choices and allowing the meaning of dfsg evolve
over time. Back to configure.ac, I'd support a choice of making a
missing configure.ac an 'important' bug, and not enough for
rejecting the package as non-dfsg.
The general rule of thumb that I've followed in similar situations in
the past (PDF files where the original source has been completely
lost, for example) is that the underlying purpose of the DFSG source provision and of free software in general is to ensure that the
recipient of the software is not at a disadvantage. In other words,
the distributor isn't allowed to hold back pieces that make it harder
for the recipient to modify the software (within the general
definition of "source," of course).
Therefore, it matters what the distributor has. If they have the
true source used to generate the file but are keeping it secret, then
to me that's a violation of the DFSG and we shouldn't participate
(even if their actions aren't technically a violation of the license
since if they own the copyright they don't need a license). This is
creating that disadvantage for the recipient that free software is
designed to prevent. But if the original source has been lost, then
everyone is on an equal footing, and I don't think there's a DFSG
violation. We may not have the true source in the intended sense,
but *no one* has the source, and therefore everyone is on an equal
footing and has equal ability to modify the software.
There is a different wrinkle in this specific case: we may have the
source but not the software that was used to generate the file from
the source. In this case, it sounds like an old version of Autoconf
was used, and we don't package that version of Autoconf any more, so
while the source is present in one sense, one can't regenerate the
file. I'm not sure the DFSG is the most useful framework for
analyzing that situation, since to me it feels more practical than freedom-based. Everyone is still in basically the same situation:
the source is available to everyone, but some work may be required to
go hunt up the old tool and regenerate the file. (This assumes a
case like Autoconf where the old releases of the tool are readily
available and not kept secret, but may be hard to get working.)
The real problem in this case is less about the DFSG and more about
the practical problems of maintaining Debian as a software
distribution: if we can't regenerate configure using software in
Debian, there are a lot of porting tasks and some bug-fixing tasks
that we can't do, and that's a problem for us. But I'm dubious that
it's a *software freedom* problem; it's more of a *software
maintenance* problem, and thus the bug severity should be based on
how much of a problem that is in practice.
(I think this is mostly a long-winded way of saying the same thing
Marco said.)
For the general case I somehow understand the consensus here on the list
that a missing configure.ac can be considered a bug but the severity
serious is not really rectified. If I understood this correctly I would reset the severity to important at the beginning of next week.
May be I interpreted
posts in this thread wrongly but I read it like serious is a to high severity. Moreover what does this mean for other packages where
configure.ac is missing?
Could you give some arguents for your feeling.
what does this mean for other packages where configure.ac is missing?
I think the fact whether a fix is simple or not does not matter for the severity of a bug. Unfortunately the solution is not as simple as
described (as I wrote in response to the said mail).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:03:14 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |