Hi Eduard.
Sorry for the reply delay, you went into my spambox :/
Thanks for the reply.
Eduard Bloch a écrit :
#include <hallo.h>
* Filipus Klutiero [Mon, Jan 16 2006, 07:25:06PM]:
Apparently m-a doesn't implement a way to avoid these problems and
Please explain how our vision of "avoiding these problems" looks like.
OK, I'll try that below.
packages using m-a range from not depending at all on gcc to depending
on a specific version of it, never really fixing the problem, so it's
Wrong. Which package depends on a specific gcc version?
My point was to indicate that module maintainers don't seem to have a
coherent approach to this problem, so there may actually be no packages
which depend on a specific version (excluding i2c-source and
lm-sensors-source, which could be considered special cases).
Nevertheless, depending on the gcc meta package is equivalent, for a
given archive snapshot, to depending on a specific gcc version.
not clear whether this should be filed against shfs or m-a.
Heh? Do "apt-cache show shfs-source | grep gcc" please.
Hum. It returns nothing, but I'm really not sure what you mean.
If this isn't reassigned to m-a, please make sure the dependencies on
gcc are OK and document that a specific gcc is needed if dependencies on
both gcc-3.3 and 4.0 are not added (which would obviously be a dirty
fix).
Do you realize that the "dependency" on gcc really comes from the kernel
we build for? How should that detected value be passed into the package
dependency in Debian databases?
Yes. As I said, adding dependencies to shfs-source on gcc would be IMO a
dirty fix, and I guess that's why I'm asking whether this is an m-a or
shfs-source bug. The point is, if there's nothing "real" done to address
the issue, shfs-source can still at least document the fact that the
right gcc version has to be installed.
But as you guess, if this is what's done, I already have a list of
packages that will get similar reports.
PS: On a second read, I think I understand why you ask this question.
When I wrote "please make sure the dependencies on gcc are OK", I didn't
mean that you should change anything, I just meant "Please confirm that
there should be no dependency on gcc, or add some".
The best thing I can do is change the mentioned warning to a failure.
Indeed, I have already considered to do so, since people are not
watching build log output all the time.
This does look like a reasonable m-a level fix.
People like me who didn't get to learning to read Perl yet may wonder
why m-a is able to note the problem in the build logs, but not to fail
immediately. As a guess the mechanism to detect the gcc version needed
might be imperfect and m-a might want to try building anyway in case the
detection was erroneous and the appropriate gcc is actually installed.
Of course, this won't be problematic for someone experienced with
Debian. But it's not sure that an inexperienced user will even attempt
reading a build log (despite the fact that it will presumably be a short
one). It might be possible to both try building even if the right gcc
appears to be missing and be more helpful for new users. Maybe m-a could
record that something looks wrong, attempt building anyway, and if it
fails, instead of just offering to read the log, first say something
like "m-a has attempted to build the module despite the fact that the
gcc version needed is missing. Installing gcc-foo and retrying should
work. Do you want to read the build log anyway?".
And if m-a maintainers are really great ;) they may implement something
that, when m-a is invoked with root permissions such as with # m-a a-i
foo;, directly offers to install gcc if the needed version seems to be
missing. This looks particularly natural given that m-a a-i already
handles fulfilling the dependencies, gcc excluded. But I won't mind
filing a wishlist bug for that part :-P
Filipus
