From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecKmbo7XXYgv for ; Mon, 7 Jan 2013 20:20:52 +0100 (CET) Received: from mps1.wohnheimg.uni-frankfurt.de (mps1.wohnheimg.uni-frankfurt.de [141.2.118.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 7 Jan 2013 20:20:52 +0100 (CET) Received: from p4fcef242.dip.t-dialin.net ([79.206.242.66] helo=[192.168.0.51]) (Authed sender Sven 'DarKRaveR' Eschenberg) by mps1.wohnheimg.uni-frankfurt.de via ESMTPSA (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim) (envelope-from ) id 1TsIFb-0008Lf-4k for dm-crypt@saout.de; Mon, 07 Jan 2013 20:20:51 +0100 Message-ID: <1357586451.2602.6.camel@laptop> From: Sven Eschenberg Date: Mon, 07 Jan 2013 20:20:51 +0100 In-Reply-To: <50EB1004.6020407@gmail.com> References: <50DF635C.90003@gmail.com> <20121230083814.GA12005@tansi.org> <5f058e3c77fb70c10ba5e65e077baa3e.squirrel@ssl.verfeiert.org> <20121230102039.GA12533@tansi.org> <50E02816.9000001@gmail.com> <1357474572.2800.50.camel@scapa> <50E9A54F.1060203@gmail.com> <1357539821.2800.67.camel@scapa> <465f60dfbd6c3ec3ef49c17d2beee680.squirrel@ssl.verfeiert.org> <50EB1004.6020407@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.0-rc1 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt