Skip Menu |
 

Download (untitled) / with headers
text/plain 3.7KiB
From krb5-bugs-incoming-bounces@PCH.mit.edu Sat Sep 12 04:21:55 2009
Return-Path: <krb5-bugs-incoming-bounces@PCH.mit.edu>
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by krbdev.mit.edu (Postfix) with ESMTP id B9CD45C01D;
Sat, 12 Sep 2009 04:21:55 +0000 (UTC)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8C4Ltkr018440;
Sat, 12 Sep 2009 00:21:55 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
[18.7.21.83])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8C3cU70013564
for <krb5-bugs-incoming@PCH.mit.edu>; Fri, 11 Sep 2009 23:38:32 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
n8C3cG2b010122
for <krb5-bugs@mit.edu>; Fri, 11 Sep 2009 23:38:17 -0400 (EDT)
Received: from ohnopublishing.net (localhost [127.0.0.1])
by mit.edu (Spam Firewall) with ESMTP id 9F7DA1F6A595
for <krb5-bugs@mit.edu>; Fri, 11 Sep 2009 23:38:14 -0400 (EDT)
Received: from ohnopublishing.net (d14-69-165-90.try.wideopenwest.com
[69.14.90.165]) by mit.edu with ESMTP id wYD9ldIwc2WuHDoU for
<krb5-bugs@mit.edu>; Fri, 11 Sep 2009 23:38:13 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of ohnobinki@ohnopublishing.net designates
69.14.90.165 as permitted sender) receiver=mit.edu;
client_ip=69.14.90.165;
envelope-from=ohnobinki@ohnopublishing.net;
Received: by ohnopublishing.net (Postfix, from userid 1000)
id 61C6633F91; Fri, 11 Sep 2009 23:38:17 -0400 (EDT)
X-DKIM: Sendmail DKIM Filter v2.8.3 ohnopublishing.net 61C6633F91
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ohnopublishing.net;
s=ohnopublishing.net; t=1252726697;
bh=fNRdRj2fYUvUTPKHnwbb5u6wCoWBFqGj7MwE3Rdetpg=;
h=To:Subject:From:Reply-To:Cc:Message-Id:Date;
b=e/ADVUxDxbDHywWIciVWcUyLABLEm5tCMEirh88F2sPfq0wURKwybILUBPPJNzwFi
1YLvuahdgSD7gUfeQgDlM3qvVQko6Wk19YrGyLbLI3nbGjnHlNTCGm/qKIpsELudrJ
HBKS8WkEgc2jbJEmDDs1Hlx+vqwV0OEtVrL+oMOY=
To: krb5-bugs@mit.edu
Subject: no option to only build clients and libs
From: Binki <ohnobinki@ohnopublishing.net>
X-send-pr-version: 3.99
Message-Id: <20090912033817.61C6633F91@ohnopublishing.net>
Date: Fri, 11 Sep 2009 23:38:17 -0400 (EDT)
X-Spam-Score: 0.10
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Sat, 12 Sep 2009 00:21:53 -0400
X-BeenThere: krb5-bugs-incoming@mailman.mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: Binki <ohnobinki@ohnopublishing.net>
Sender: krb5-bugs-incoming-bounces@PCH.mit.edu
Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu


Show quoted text
>Submitter-Id: net
>Originator: Nathan Phillip Brink
>Organization:

Show quoted text
>Confidential: no
>Synopsis: No option to only build client and libs
>Severity: non-critical
>Priority: low
>Category: krb5-misc
>Class: change-request
>Release: 1.6.3
>Environment:

System: Linux ohnopublishing.net 2.6.30-gentoo-r4athlon64x2_2009.05.31 #1 SMP Fri Aug 21 12:50:25 EDT 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux


Show quoted text
>Description:
It appears from the online documentation that mit-krb5 and its build system does not support building only libs/clients. There should be options for building just the basic, necessary clients (kinit, kdestroy, kpasswd, klist, maybe kadmin) and libs. The primary number of systems which will have mit-krb5 installed do not need or have no reason to run the KDC. Building and installing that component is a waste of time and space for those machines.
Show quoted text
>How-To-Repeat:
Read documentation and compile/install mit-krb5
Show quoted text
>Fix:
An option to only build the necessary client programs should be provided. Preferrably, the krb5-enabled system-util replacements would be optional as well, but those are at least still useful on client machines which aren't acting as KDCs ;-)
By the standards of most modern software packages, the entirety of krb5
builds in very little time and takes very little space. Moreover, most
people do not build krb5 themselves; they get it from an OS
distribution. OS packages typically build all of krb5 and then split up
the result into multiple binary packages, so they do not need build
system support to separate clients, libraries, and so forth.

Do you have a particular need in this regard? If this is just a matter
of principle, I don't think we want to further complicate our build system.
Date: Sat, 12 Sep 2009 12:57:39 -0400
From: Nathan Phillip Brink <ohnobinki@ohnopublishing.net>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6561] No option to only build client and libs
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.4KiB
Greg Hudson via RT wrote:
Show quoted text
> By the standards of most modern software packages, the entirety of krb5
> builds in very little time and takes very little space. Moreover, most
> people do not build krb5 themselves; they get it from an OS
> distribution.
As I do, using Gentoo.

Show quoted text
> OS packages typically build all of krb5 and then split up
> the result into multiple binary packages, so they do not need build
> system support to separate clients, libraries, and so forth.
Many popular packages' build systems support conditional
compilation/installation of portions of the software.

Also, distributions somewhat rely on a program's build system to build
the software. For example, Debian (I'm guessing), Gentoo, and LFS depend
on your build system to produce the binaries andto install binaries
where they belong. MIT's krb5 ironically recognizes this by providing an
install target in its Makefiles.

The distribution's task of making certain features of your package
optional is somewhat dependent on your buildsystem's support for such.
If every single distribution which packages mit-krb5 has to generate and
maintain its own patches to the mit-krb5 buildsystem to have conditional
building support, effort is wasted. Also, if your buildsystem builds
programs which the distribution isn't installed, the user has to wait
for those portions to be built. Thus, I think the proper place to
implement conditional building and installation is within your buildsystem.

A related task would be supporting installation of the system-utility
replacement binaries, but that doesn't bother me as greatly as the
inability to have even general control over what gets compiled when make
is run.

Show quoted text
>
> Do you have a particular need in this regard? If this is just a matter
> of principle, I don't think we want to further complicate our build system.
I'm sorry, it is a matter of two principles.
1. It should be possible to decide what gets installed and compiled when
using compiling and installing mit-krb5.
2. Multiple distributions shouldn't duplicate effort in hacking your
buildsystem or otherwise breaking it apart.

If you are willing to consider this issue, I think I could put a patch
together. I haven't looked too closely at your current buildsystem. I'm
now just trying to establish that this bug is valid ;-). I initially
wondering if this functionality just wasn't documented online, but you
have hinted that the functionality doesn't exist.

--
binki
From: Russ Allbery <rra@stanford.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6561] No option to only build client and libs
Date: Sat, 12 Sep 2009 11:27:46 -0700
RT-Send-Cc:
"ohnobinki@ohnopublishing.net via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
> The distribution's task of making certain features of your package
> optional is somewhat dependent on your buildsystem's support for such.
> If every single distribution which packages mit-krb5 has to generate and
> maintain its own patches to the mit-krb5 buildsystem to have conditional
> building support, effort is wasted. Also, if your buildsystem builds
> programs which the distribution isn't installed, the user has to wait
> for those portions to be built. Thus, I think the proper place to
> implement conditional building and installation is within your
> buildsystem.

I suspect this is a Gentoo-specific problem. For Red Hat and Debian at
least, and I suspect for all distribution packaging that isn't based on
the end-user compiling their own version of the software, there's no need
to support building portions of the software. Building Debian packages or
RPMs always builds all related packages, and then the user chooses which
of those to install.

--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Date: Sat, 12 Sep 2009 14:48:37 -0400
From: Nathan Phillip Brink <ohnobinki@ohnopublishing.net>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6561] No option to only build client and libs
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.5KiB
Russ Allbery via RT wrote:
Show quoted text
> "ohnobinki@ohnopublishing.net via RT" <rt-comment@krbdev.mit.edu> writes:
>
>> The distribution's task of making certain features of your package
>> optional is somewhat dependent on your buildsystem's support for such.
>> If every single distribution which packages mit-krb5 has to generate and
>> maintain its own patches to the mit-krb5 buildsystem to have conditional
>> building support, effort is wasted. Also, if your buildsystem builds
>> programs which the distribution isn't installed, the user has to wait
>> for those portions to be built. Thus, I think the proper place to
>> implement conditional building and installation is within your
>> buildsystem.
>
> I suspect this is a Gentoo-specific problem. For Red Hat and Debian at
> least, and I suspect for all distribution packaging that isn't based on
> the end-user compiling their own version of the software, there's no need
> to support building portions of the software. Building Debian packages or
> RPMs always builds all related packages, and then the user chooses which
> of those to install.
You do not understand what I am trying to say. Gentoo could add support
to their buildscripts to patch your buildsystem so that it could
conditionally compile sources. Gentoo could also just delete installed
binaries that the user doesn't want installed. However, both of these
methods are incorrect ways of addressing a problem with mit-krb5's
buildsystem: its lack of conditional building/installation.

Gentoo does not support users just compiling their own software and
manually installing it. This is not a good way to manage software.
However, in Gentoo, users are encouraged and mostly required to compile
software locally using ebuilds which are similar in principle to
specfiles (any redhat users?) and use a package manager. Just as many
distributions maintain patches against packages, Gentoo applies patches
to mit-krb5 before it is compiled and installed. For some packages
(including mit-krb5), there are patches that add missing functionality
to buildsystems (sometimes in Gentoo-specific ways, but this bug is not
an example of that).

However, it is preferable to get things fixed upstream. I was submitting
this request here because its fix would benefit many users of mit-krb5.
And I was hoping that this change might trickle down so that Gentoo devs
could easily add an option to the ebuild to only build and install the
minimal set of libs and clients of mit-krb5. This would also ease the
job of other distribution which mangle this package anyways.

--
binki
From: Russ Allbery <rra@stanford.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6561] No option to only build client and libs
Date: Sat, 12 Sep 2009 11:58:21 -0700
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.4KiB
"ohnobinki@ohnopublishing.net via RT" <rt-comment@krbdev.mit.edu> writes:
Show quoted text
> Russ Allbery via RT wrote:
>> "ohnobinki@ohnopublishing.net via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
>>> The distribution's task of making certain features of your package
>>> optional is somewhat dependent on your buildsystem's support for such.
>>> If every single distribution which packages mit-krb5 has to generate
>>> and maintain its own patches to the mit-krb5 buildsystem to have
>>> conditional building support, effort is wasted. Also, if your
>>> buildsystem builds programs which the distribution isn't installed,
>>> the user has to wait for those portions to be built. Thus, I think the
>>> proper place to implement conditional building and installation is
>>> within your buildsystem.

Show quoted text
>> I suspect this is a Gentoo-specific problem. For Red Hat and Debian at
>> least, and I suspect for all distribution packaging that isn't based on
>> the end-user compiling their own version of the software, there's no
>> need to support building portions of the software. Building Debian
>> packages or RPMs always builds all related packages, and then the user
>> chooses which of those to install.

Show quoted text
> You do not understand what I am trying to say.

I think that I do, but am addressing a more limited part of your point
than I think you're realizing. You made the argument that "if every
single distribution which packages mit-krb5 has to generate and maintain
its own patches to the mit-krb5 buildsystem to have conditional building
support, effort is wasted." I'm pointing out that the only distribution
that is likely to care is Gentoo; this is not a useful feature for other
distributions that don't use the approach that Gentoo takes to building
software.

That doesn't mean that your feature proposal is without merit, only that
the scope of expected usage is somewhat smaller than I think your bug
report reflected.

Show quoted text
> However, it is preferable to get things fixed upstream. I was submitting
> this request here because its fix would benefit many users of mit-krb5.
> And I was hoping that this change might trickle down so that Gentoo devs
> could easily add an option to the ebuild to only build and install the
> minimal set of libs and clients of mit-krb5.

Of course. I think the question is whether it adds complexity to the
build system that the Kerberos maintainers don't want to cope with.

--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
If this build system support would make life easier for Gentoo's package
system, that's a valid use case. I don't think other OS packaging
systems would make use of the functionality (they would still use "make
install" and then use file lists to split up the binary packages), but
even one distribution's needs are relevant.

So, no promises, but if I have time I will see how complicated this
really is.