On Thu, 14 May 2015 23:25:20 +0200 Vincent Bernat <bernat@debian.org> wrote: > ❦ 14 mai 2015 14:57 +0100, Neil Williams <codehelp@debian.org> : > > >> More seriously, but this needs some additional work, it should be > >> easier to manage persistent build dependencies. The first time you > >> build a package, it retrieves and install all deps. The second > >> time, the build environment is already here. > > > > That's a (serious) bug, not a feature. > > > > Either you want clean build environments or you are prepared to > > build in dirty ones, in which case there's little point using a > > container at all. > > > > A package cache is different, that's what pbuilder uses - that > > avoids the risk of stale packages being installed, not being > > updated and breaking the build. Either do it by uninstalling at the > > end of the build or by using a disposable container (LVM snapshot > > or pbuilder chroot). At all costs, avoid the false appeal of a > > dirty container which gets you none of the advantages and all of > > the problems of building on a developer box with no container at > > all. > > > > Were you thinking of a package cache or a dirty container? > > > > Any build system which allows for dependencies of a previous build > > to exist at the start of the next build is irretrievably broken and > > unfit for purpose. All you can allow to exist at the start of the > > build is build-essential. > > For some packages, installing the dependencies can take more time than > building the package. An inevitable cost of building software that has a significant stack of dependencies. However, each of those dependencies needs to be cleaned up or the build will generate erroneous binaries. Use a cache if download speeds are a problem (less likely with modern network connections). Use an SSD if installation time is a problem. > This makes use of pbuilder/cowbuilder quite > tiresome. If the whole dependencies are already here, this becomes > more enjoyable. Short term gain for long term pain. It is not worth it - you may save a small bit of time now, it can take weeks to work out why buildA works, buildB fails and buildC works when the fault actually exists in a dependency which wasn't upgraded ahead of buildB because someone was as lazy as the writers of the build system. Never underestimate how much time developers will waste on identifying that the bug isn't in the code they know but in some broken upgrade of a dependency which should never have been left behind. You need to build things as close as possible to how Debian builds things too - otherwise, bug reports won't make any sense (bug reports relating to the dependencies, even if you don't put your own code into Debian). > This is not a dirty container. Sorry, it is dirty. It just is. It's dirty in the worst possible manner - stuff directly relating to the builds you care about is going to end up out of date or possibly even corrupted by a mis-configured build. There's nothing "modern" about debugging issues arising from dirty containers, it's completely unnecessary and a false economy. There are good reasons why all of the existing packaging systems use clean environments and either remove all build-dependencies beyond build-essential or throw away the dirty system and replace with a fresh snapshot, again with only build-essential installed. Any new build system which deliberately forgoes these lessons deserves to be ignored and sent to the a permanent home in /dev/null. > Only the dependencies needed for the > packages are retrieved. If the build environment for the package > doesn't exist, a new environment is created. Old environments are > removed after a day. Something like that. A container where the dependencies remain installed is a dirty container. What happens when there is a transition in one and someone forgets to update the dependencies to save time? Pybit arose from just this situation - we had (internal) "time saver" build software and when it cost us 4 weeks work for 4 developers & 2 testers to find out that a previous build had mangled some of the pango support files, we swore never to do so again. Fix your software, if necessary. What we did was split the codebase up into many smaller packages. Most of these needed many fewer build-dependencies than the code as a whole. Most of these actually changed only rarely, so the same build could be tested again and again. That limited the potential scope of problems to a smaller set of code, making things much easier to track. This isn't new, this isn't surprising. What *is* surprising and what needs to be thrown back in the faces of all those who propose such lunacy is that the need to be "modern" must NOT involve throwing away both security and established good practice in a vain attempt at "convenience". That's entirely and utterly the WRONG way to do things. Please don't reinvent the problems fixed long, long ago. It won't bother those who do things properly but it will waste vast amounts of your time which you willingly sacrificed on such a misguided route in the name of the false god called "convenience". -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpIOEmj6oTvs.pgp
Description: OpenPGP digital signature