Hi Milan, I think you misunderstood my post. I merely pointed out, that the way the current build handles things is the way to do it and is the usual way of doing things. What I tried to point out is, that if a special feature has specific build requirements, then a distributor's/maintainer's job who builds the package is to take care of all this. I tried to object the idea of packaging all necessary headers (of external deps) with cryptsetup into one package. Sorry, if I did not make this clear enough. Regards -Sven On Mon, 2013-01-07 at 19:12 +0100, Milan Broz wrote: > On 01/07/2013 12:21 PM, Sven Eschenberg wrote: > > Exactly, when the header is missing, you can hardly compile support in, as > > the compiler does not know the interface. Putting the header into > > cryptsetup package is not an option, as it is not part of cryptsetup > > itself, but merely the kernel and possibly changes from time to time. > > > > Usually, a package describes its dependencies and then the builder's job > > is to provide an adequate build environment to get the build he wants. > > Well, it would be nice to have exact bug report if you see some problem, > please test current git version. > > The --disable-kernel_crypto switch is required only for systems where > kernel with userspace crypto API will never be available. > > For other systems it is maintainer's job to set up dependences properly > (require proper kernel headers). > > FYI: you will see this warning (RHEL5, as example of old system) > ... > checking for linux/if_alg.h... no > configure: error: You need Linux kernel headers with userspace crypto interface. (Or use --disable-kernel_crypto.) > > Here (RHEL5) the only option is to use --disable-kernel_crypto. > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
