building in a clean chroot vs. building on actual system

quequotion · 2015-10-19 06:47:48

This came up against a couple of bugs I reported today.

I understand the premise of the argument: if the bug doesn't happen in a clean chroot, it must be user error. It's a good argument, and a good principle for debugging. I get that this overcomes the nightmare of defining a "supported installation" for a rolling-release distribution. It also avoids the madness of trying to cover every possible build environment.

I have a counter argument: building packages exclusively in clean chroots may prevent packagers from noticing problems with the packaging and fixing such issues improves packages.

Before you go right back to the user error perspective, here's a theoretical* example:

"somepackage" is built in a clean chroot for distribution in the arch repositories. during the build, a certain feature is left out because no library for building it is installed--this case does not break compilation, and doesn't get the packager's attention. "somepackage" goes into distribution in the arch repositories without that feature, but the ABS packaging does not explicitly disable the feature.

Perhaps, someday, a user of the binary package will expect that feature to be there, not find it, and not know why it isn't there (since it doesn't appear to be explicitly disabled). This could be resolved two ways, both starting with the user making a bug report.

A. If the user can convince the packager that the problem can be solved in packaging and that the feature is worth supporting, the packager might add explicit support for the feature, making sure the library to support the feature exists, and adding that library as makedepends().

B. If the feature seems unimportant, or conflicts with something, the packager might explicitly disable that feature (and allow the user to upload their own package with the feature explicity enabled and additional dependencies to aur).

C. If anything, I've learned from Arch's bugtracker that there is always an option C, especially when you only expect two options.

*This isn't what happened. No one has come looking for the feature in the package I reported as of yet to my knowledge. I only came across it because I am obsessively trying to build everything (and almost getting it done) and I don't really care which way it gets resolved. It's just a theory.

So my question is, should we only acknowledge problems that occur in clean chroots, or is there some value in fixing problems that occur on a live system?

Last edited by quequotion (2015-10-20 13:24:14)

quequotion · 2015-10-19 06:55:04

To make it much more simple, I think the results of "field testing" packages on real systems deserve some consideration, although I recognize the necessity and authority of "scientific testing" in clean chroots.

Last edited by quequotion (2015-10-19 06:55:43)

olive · 2015-10-19 08:08:34

The "if the bug doesn't happen in a clean chroot, it must be user error" can't of course be taken literally. Anything that's kernel or systemd related won't depend on the chroot but of the host system; and that include most hardware problem. I think a properly configured package should explicitly enable or disabled the libraries it is built against and not give a diffrent package according to what is installed in the build system.

Building package in a clean chroot is a good idea, I think, to distribute package. A package where an optional dependency feature was inadvertently enabled by picking up a libraries on the host give a package with an additional missing dependency that probably won't work unless the additional dependency is installed and this is definitively a broken package.

Last edited by olive (2015-10-19 08:12:13)

Allan · 2015-10-19 09:06:14

Option D - all the packages you are looking for are available in [mutlilib]

You probably no long have it enabled in your pacman.conf...

quequotion · 2015-10-19 12:46:15

Allan wrote:

Option D - all the packages you are looking for are available in [mutlilib]
You probably no long have it enabled in your pacman.conf...

I am intentionally building them from source. I have the repositories enabled so that I can do this with "yaourt -sbb package".

Allan · 2015-10-19 13:24:47

Check you pacman.conf. You were not finding multilib packages - this is a common thing for people to miss when merging pacman.conf.pacnew.

quequotion · 2015-10-20 03:20:17

Allan wrote:

Check you pacman.conf. You were not finding multilib packages - this is a common thing for people to miss when merging pacman.conf.pacnew.

I generally do not merge new configuration files when given the choice.
pacman.conf has not changed since August 24th, and includes:

[multilib]
Include = /etc/pacman.d/mirrorlist

Not that this has anything to do with the thread topic.

Those packages are now showing up. It's likely that there was some kind of problem with my local mirror; I have been having problems with my local mirror recently.

Again: not related to thread topic.

Last edited by quequotion (2015-10-20 03:23:08)

quequotion · 2015-10-20 03:40:51

Here's another example:

"somepackage" and "lib32-somepackage" are built in clean chroots for distribution in the arch repositories. The two packages are not intended to conflict. "somepackage" includes certain files that "lib32-somepackage" must not. For some unspecified reason, those files build in "somepackage" in a clean chroot, but do not when "lib32-somepackage" is built in a clean chroot, so it doesn't get the packager's attention and the unwanted files are not explicitly removed or prevented from building in "lib32-somepackage".

Are the "clean" chroots for the two packages different? Why would one package build differently from the other if they are built in the same environment with only architechture-specific flags different between them? Wouldn't it be prudent to do something about this just in case the magic wears off some day?

Scimmia · 2015-10-20 04:08:31

It's not "some unspecified reason", it's because the packager specifically didn't include deps/makedeps on something, so the configure script doesn't get confused and everything works as intended.

quequotion · 2015-10-20 06:02:39

Scimmia wrote:

It's not "some unspecified reason", it's because the packager specifically didn't include deps/makedeps on something, so the configure script doesn't get confused and everything works as intended.

Is that the reason which had not been specified? Sounds like a lot of trouble to go to, setting up individual build environments per-package rather than add 12 characters so the package builds properly regardless of the environment. Why contrive various build environments to get certain packaging results rather than use built-in configuration and compilation options to ensure the same results in any environment? Scripts don't get confused; if a script could be told not to do the thing it shouldn't do, isn't that better than relying on oustide factors that (might) prevent it from doing the thing it shouldn't do? Besides, we have PKGBUILDs to contrive packages into whatever shape we need them to be.

I know it isn't possible to proof against every possible build environment, but why just leave a problem as it is when something could easily be done about it? Aren't more resilient and convenient packages a good thing? If the packages are all (or at least, mostly) the same versions as those in the archlinux repositories, I don't think it's unreasonable--however officially unsupported--to expect they are safe to build alongside each other.

I'm not talking about a whole new standard of packaging, just considering an occasional minor fix that makes no effective difference for the "clean" chroot build, but solves an actual problem for users building from source on an actual system.

As it is, arch is only a hop, skip and a jump away from building entirely from source*. There are some rough edges in ABS that prevent this from being done with a simple "yaourt -Syubb". These problems could be fixed, but I understand the administrative viewpoint that the packages pass the recognized tests and effort beyond that is better spent on recognized problems, especially in a mostly volunteer enterprise.

If I could find a reliable means to do so, I'd integrate the ABS svn into my package managment, so packages would automatically rebuild and reinstall on commit--keeping my system up-to-date in as close to real time as possible. It would also be nice to re-write pacstrap to do initial installs by building packages before installing them.

*I do not intend to beat a dead horse over the merits of doing this. Suffice to say that I think it is an option worth offering to interested users.

Last edited by quequotion (2015-11-15 14:50:33)

Arch Linux

#1 2015-10-19 06:47:48

building in a clean chroot vs. building on actual system

#2 2015-10-19 06:55:04

Re: building in a clean chroot vs. building on actual system

#3 2015-10-19 08:08:34

Re: building in a clean chroot vs. building on actual system

#4 2015-10-19 09:06:14

Re: building in a clean chroot vs. building on actual system

#5 2015-10-19 12:46:15

Re: building in a clean chroot vs. building on actual system

#6 2015-10-19 13:24:47

Re: building in a clean chroot vs. building on actual system

#7 2015-10-20 03:20:17

Re: building in a clean chroot vs. building on actual system

#8 2015-10-20 03:40:51

Re: building in a clean chroot vs. building on actual system

#9 2015-10-20 04:08:31

Re: building in a clean chroot vs. building on actual system

#10 2015-10-20 06:02:39

Re: building in a clean chroot vs. building on actual system

Board footer