Jonas wrote: >Quoting Steve McIntyre (2017-07-17 02:00:25) > >> But a *lot* of the infrastructure we use to run Debian is not exactly >> what's been packaged, as already mentioned. Look at dak. debian-cd, >> live-wrapper et al *are* packaged, but we're not *necessarily* using >> the exact code that's in the stable archive at any point. We're >> typically using code from git on the build machines, to allow for more >> flexibility in terms of changes to build scripts as problems arise. We >> release things to the archive periodically as a convenience to users, >> but serious use often necessitates using git too. This isn't going to >> change any time soon. > >Sure it would be ideal to keep track of *everything* we do, including >how we run services. But as mentioned above I distinguish between >services and things directly affecting our product. Would you agree >that at first limiting the task to covering only the tools directly >affecting our product (e.g. debian-cd, liver-wrapper, libisofs) is more >realistic than tracking also e.g. dak and Alioth? > >For starters, I believe they all exist as packages in Debian, it is >"only" a matter of releasing into Debian the specific version used in >production. > >...but since they seemingly are excempt from Debian Policy exactly >because the code used is not packaged code, we cannot track this issue >in the same way we track issues with packages. We can "ask on the >list"...
I've corrected several of your incorrect assertions already. I'm bored of this. Making images often requires tweaks to the build script at/near release time. The archive continues to be a moving target until very close to that time. More than once we've fixed things or added workarounds in the image generation scripts *on release day*. I'm not going to remove the ability to do that and make working images to pander to your ideals here. -- Steve McIntyre, Cambridge, UK. st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
