#include <hallo.h>
* Filipus Klutiero [Fri, Jan 20 2006, 03:56:56AM]:
> >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.
As said, there is no point in making a module-source package depend on
certain compiler version because they are independent. The kernel
defines that dependency and it can only be resolved while preparing the
actual build. It is not even done by "m-a prepare", but I will change
that a bit and install the compiler needed for the current kernel (or
the alternative build-tree(s) specified with -k/-l options).
> >>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.
That you filled your report against the wrong package. Luckily I am the
author of m-a as well and yes, you are right, it should be fixed
up-front in m-a.
> >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.
Yes. And those who really want to use the wrong compiler can still use
the --force switch.
> 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?".
Hmm, an interactive solution. Sounds feasible... a verbose failure in
non-interactive mode and a such prompt in cli/dialog modes.
> 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
That would be another prompt: 'Build essential packages are missing,
your system is not ready to compile modules. Do you wish the automatic
environment preparation to be started now?'
Please correct that if you are a native speaker or suggest a better
phrase.
Eduard.
--
Planst du für ein Jahr, so säe Korn, planst du für ein Jahrzehnt, so
pflanze Bäume, planst du fürs Leben, so bilde Menschen.
-- Kuan Tzu
