This was covered briefly in a couple of emails on this list a couple of weeks ago but I see this as a bug, further discussion please . . .
Mock no longer uses a login shell for builds.
The way I discovered this is that the ipsec-tools package stopped building. The reason is that it has a BuildRequires for the krb5-devel package, from which it uses krb5-config.
krb5-config is installed in /usr/kerberos/bin/, and the user's path is provided by /etc/profile.d/krb5-devel.sh
No user shell, therefore no path, and configure fails to find krb5-config.
The simple solution for this is to add the following to the %build section of the spec file for ipsec-tools:
source /etc/profile.d/krb5-devel.sh
Having put that into the spec file, there's potential for what would otherwise be a perfectly acceptable change to the krb5 package to break builds of other packages that have a BuildRequire for it.
I'm afraid that this might lead to a proliferation of small changes to spec files that create unneeded dependencies.
I'm interested in what other people think about this.
Steve
On Wed, 2007-12-19 at 14:14 -0600, Steve Conklin wrote:
This was covered briefly in a couple of emails on this list a couple of weeks ago but I see this as a bug, further discussion please . . .
Mock no longer uses a login shell for builds.
The way I discovered this is that the ipsec-tools package stopped building. The reason is that it has a BuildRequires for the krb5-devel package, from which it uses krb5-config.
krb5-config is installed in /usr/kerberos/bin/, and the user's path is provided by /etc/profile.d/krb5-devel.sh
No user shell, therefore no path, and configure fails to find krb5-config.
A lot of the qt dependent packages are in the same boat, one of mine hit this today.
~spot
On Wed, Dec 19, 2007 at 02:14:05PM -0600, Steve Conklin wrote:
Mock no longer uses a login shell for builds.
The way I discovered this is that the ipsec-tools package stopped building. The reason is that it has a BuildRequires for the krb5-devel package, from which it uses krb5-config.
krb5-config is installed in /usr/kerberos/bin/, and the user's path is provided by /etc/profile.d/krb5-devel.sh
No user shell, therefore no path, and configure fails to find krb5-config.
I think mock is wrong. It's obvious that the devel packages assume developers (like package builders, either human or not ;-)) run the /etc/profile.d scripts. The same holds for some JVM's, IIRC.
On Wed, 19 Dec 2007 22:00:10 +0100 Jos Vos jos@xos.nl wrote:
I think mock is wrong. It's obvious that the devel packages assume developers (like package builders, either human or not ;-)) run the /etc/profile.d scripts. The same holds for some JVM's, IIRC.
How does this work though when installing the -devel packages? Are you expected to log out and log back into your shell to actually do something useful? That doesn't seem right to me.
On Mi Dezember 19 2007, Jesse Keating wrote:
On Wed, 19 Dec 2007 22:00:10 +0100
Jos Vos jos@xos.nl wrote:
I think mock is wrong. It's obvious that the devel packages assume developers (like package builders, either human or not ;-)) run the /etc/profile.d scripts. The same holds for some JVM's, IIRC.
How does this work though when installing the -devel packages? Are you expected to log out and log back into your shell to actually do something useful? That doesn't seem right to me.
This is how it works with every package that drops something into /etc/profile.d. Why is it not right for -devel packages?
Regards, Till
On Wed, 19 Dec 2007 22:22:23 +0100 Till Maas opensource@till.name wrote:
This is how it works with every package that drops something into /etc/profile.d. Why is it not right for -devel packages?
I didn't ask if it was done elsewhere. I think it's a terrible user experience, that if use of a package is going to depend on shell variables, and you have to reload your environment to make use of them.
On Wed, 2007-12-19 at 17:02 -0500, Jesse Keating wrote:
On Wed, 19 Dec 2007 22:22:23 +0100 Till Maas opensource@till.name wrote:
This is how it works with every package that drops something into /etc/profile.d. Why is it not right for -devel packages?
I didn't ask if it was done elsewhere. I think it's a terrible user experience, that if use of a package is going to depend on shell variables, and you have to reload your environment to make use of them.
Perhaps these scripts should be sourced in %post?
~spot
On Wed, Dec 19, 2007 at 05:02:47PM -0500, Tom spot Callaway wrote:
Perhaps these scripts should be sourced in %post?
Useless, as %post is an own shell, everything sourced there is lost immediately.
On Wed, Dec 19, 2007 at 05:02:02PM -0500, Jesse Keating wrote:
I didn't ask if it was done elsewhere. I think it's a terrible user experience, that if use of a package is going to depend on shell variables, and you have to reload your environment to make use of them.
I see your point, but by adding packages you're in fact changing your system. Sometimes even a reboot is required. And when your package has a service that is started by default (and thus is expected to run after installing the package), this service will only be started after a reboot (or manually, of course).
On Wed, 2007-12-19 at 22:00 +0100, Jos Vos wrote:
On Wed, Dec 19, 2007 at 02:14:05PM -0600, Steve Conklin wrote:
Mock no longer uses a login shell for builds.
The way I discovered this is that the ipsec-tools package stopped building. The reason is that it has a BuildRequires for the krb5-devel package, from which it uses krb5-config.
krb5-config is installed in /usr/kerberos/bin/, and the user's path is provided by /etc/profile.d/krb5-devel.sh
No user shell, therefore no path, and configure fails to find krb5-config.
I think mock is wrong. It's obvious that the devel packages assume developers (like package builders, either human or not ;-)) run the /etc/profile.d scripts. T
It's only broken development packages which require setting environment variables like this. The correct way to do parallel installation is:
http://www106.pair.com/rhp/parallel.html
I'm sure there's some historical reason krb5-config is not in /usr/bin, but it's a design flaw in the software.
The environment variable approach seems easy (no need to rename binaries), but falls over when you need to compile applications against multiple library versions.
On Wed, Dec 19, 2007 at 05:21:32PM -0500, Colin Walters wrote:
On Wed, 2007-12-19 at 22:00 +0100, Jos Vos wrote:
On Wed, Dec 19, 2007 at 02:14:05PM -0600, Steve Conklin wrote:
Mock no longer uses a login shell for builds.
The way I discovered this is that the ipsec-tools package stopped building. The reason is that it has a BuildRequires for the krb5-devel package, from which it uses krb5-config.
krb5-config is installed in /usr/kerberos/bin/, and the user's path is provided by /etc/profile.d/krb5-devel.sh
No user shell, therefore no path, and configure fails to find krb5-config.
I think mock is wrong. It's obvious that the devel packages assume developers (like package builders, either human or not ;-)) run the /etc/profile.d scripts. T
It's only broken development packages which require setting environment variables like this. The correct way to do parallel installation is:
http://www106.pair.com/rhp/parallel.html
I'm sure there's some historical reason krb5-config is not in /usr/bin, but it's a design flaw in the software.
The environment variable approach seems easy (no need to rename binaries), but falls over when you need to compile applications against multiple library versions.
So, are we going to mandate in the packaging guidelines that packages *not* use environment variables and that all packages should use pkg-config?
That is the issue here.
Because if we dont do that, then we end up in the odd situation where a legal package that passes review cannot be built with the official fedora build tool. -- Michael
On Wed, 2007-12-19 at 17:13 -0600, Michael E Brown wrote:
So, are we going to mandate in the packaging guidelines that packages *not* use environment variables
Thinking about this a bit more the krb thing is really ugly but probably not something that needs to be prohibited. Having mock use a login shell isn't the end of the world.
The way to think about this is that's it's just as broken as library software which ships a binary named foo-config for libfoo2 and libfoo3; there is a conflict between /usr/bin/foo-config and so you can't have them both installed at the same time.
and that all packages should use pkg-config?
pkg-config is a good way to sanely manage development libraries, but it's not the one true way (i.e. we don't need to mandate it) - if some software wants to do something else that's fine, as long as they do it correctly =) A link to that page though in the guidelines would be a good idea so we can help upstreams understand how to be a good Linux citizen.
On Wed, Dec 19, 2007 at 06:37:04PM -0500, Colin Walters wrote:
On Wed, 2007-12-19 at 17:13 -0600, Michael E Brown wrote:
So, are we going to mandate in the packaging guidelines that packages *not* use environment variables
Thinking about this a bit more the krb thing is really ugly but probably not something that needs to be prohibited. Having mock use a login shell isn't the end of the world.
The way to think about this is that's it's just as broken as library software which ships a binary named foo-config for libfoo2 and libfoo3; there is a conflict between /usr/bin/foo-config and so you can't have them both installed at the same time.
and that all packages should use pkg-config?
pkg-config is a good way to sanely manage development libraries, but it's not the one true way (i.e. we don't need to mandate it) - if some software wants to do something else that's fine, as long as they do it correctly =) A link to that page though in the guidelines would be a good idea so we can help upstreams understand how to be a good Linux citizen.
Ok. So it seems that we have general consensus that it wouldnt be the end of the world for mock to use a login shell.
I have checked in a patch to upstream mock git repository.
Can some of the affected parties please check it out and see if it fixes your issue? We can release a fixed version soon if this works out. -- Michael
On Wed, Dec 19, 2007 at 05:41:57PM -0600, Michael E Brown wrote:
On Wed, Dec 19, 2007 at 06:37:04PM -0500, Colin Walters wrote:
On Wed, 2007-12-19 at 17:13 -0600, Michael E Brown wrote:
So, are we going to mandate in the packaging guidelines that packages *not* use environment variables
Thinking about this a bit more the krb thing is really ugly but probably not something that needs to be prohibited. Having mock use a login shell isn't the end of the world.
The way to think about this is that's it's just as broken as library software which ships a binary named foo-config for libfoo2 and libfoo3; there is a conflict between /usr/bin/foo-config and so you can't have them both installed at the same time.
and that all packages should use pkg-config?
pkg-config is a good way to sanely manage development libraries, but it's not the one true way (i.e. we don't need to mandate it) - if some software wants to do something else that's fine, as long as they do it correctly =) A link to that page though in the guidelines would be a good idea so we can help upstreams understand how to be a good Linux citizen.
Ok. So it seems that we have general consensus that it wouldnt be the end of the world for mock to use a login shell.
I have checked in a patch to upstream mock git repository.
Sorry forgot to post link: git://git.fedorahosted.org/git/mock.git
Can some of the affected parties please check it out and see if it fixes your issue? We can release a fixed version soon if this works out.
-- Michael
Java-side we've had build processes that depended on env variable for some years but the files containing those variables have always been explicitely sourced by build scripts without relying on profile.d
On Wednesday 19 December 2007, Jos Vos wrote:
It's obvious that the devel packages assume developers (like package builders, either human or not ;-)) run the /etc/profile.d scripts.
I disagree. Things should Just Work, and in this particular case that's easily accomplished by sourcing whatever needs to be sourced during the build in specfiles.
On Wed, Dec 19, 2007 at 02:14:05PM -0600, Steve Conklin wrote:
This was covered briefly in a couple of emails on this list a couple of weeks ago but I see this as a bug, further discussion please . . .
Mock no longer uses a login shell for builds.
Incorrect. Mock *NEVER* used a login shell for builds.
It *just* *so* *happened* that your personal account's environment variables *leaked* into the chroot.
This is wrong on so many different levels it's not even funny. If your host environment variables were different from the chroot's (building F-9 packages on F-7 host, for instance) and any of the paths were changed, then your build would silently get the wrong results.
The new mock behaviour is that the environment is cleaned, and host environment variables wont get leaked into the chroot.
The way I discovered this is that the ipsec-tools package stopped building. The reason is that it has a BuildRequires for the krb5-devel package, from which it uses krb5-config.
krb5-config is installed in /usr/kerberos/bin/, and the user's path is provided by /etc/profile.d/krb5-devel.sh
No user shell, therefore no path, and configure fails to find krb5-config.
The simple solution for this is to add the following to the %build section of the spec file for ipsec-tools:
source /etc/profile.d/krb5-devel.sh
Seems to me pkgconfig or some other such mechanism should be preferred over /etc/profile.d/. What happens to those poor users who use an alternate shell?
Having put that into the spec file, there's potential for what would otherwise be a perfectly acceptable change to the krb5 package to break builds of other packages that have a BuildRequire for it.
pkgconfig.
I'm afraid that this might lead to a proliferation of small changes to spec files that create unneeded dependencies.
I'm interested in what other people think about this.
A) We wont ever again let host env vars pollute the chroot. period.
B) Why not just do a %post -p '/bin/bash -l'? -- Michael