Quoting Steve McIntyre (2017-07-17 02:00:25) > Jonas wrote: > >Quoting Steve McIntyre (2017-07-16 22:14:29) > >> Jonas wrote: > >> >Quoting Andrey Rahmatullin (2017-07-16 19:28:06) > >> >> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard > >> >> wrote: > >> >> > Is our install images excepmt from our Policy that all > >> >> > dependencies must be in Debian, or am I mistaken that we have > >> >> > such Policy? > >> >> Do we? The Debian Policy covers only debs. > >> >> Also, dak isn't in the archive either. > >> > > >> >I thought Policy covered what we distribute - which excludes dak > >> >but includes libisofs code embedded in installer images. > >> > >> Can you identify any code at all from libisofs which is embedded in > >> the images? I'm honestly not aware of any. > > > >I believe the embedded MBR is part of the libisofs project. > > No, the MBR is generated from the isolinux/syslinux packages. xorriso > (libisofs) just updates some pointers in there to point at the El > Torito bootable images, to add a fake partition table, etc. Ok, so I stand corrected in that libisofs do not provide code (like e.g. a library). Thanks for clarifying. I still believe that libisofs are closer tied to our product than to our surrounding services: We (or derivatives) may upgrade/replace/skip Apache or dak or Alioth and still deliver an identical product, but upgrading libisofs may directly cause an image to fail or succeed. Isn't that exactly the reason you have chosen to not rely on Debian packages but stayed in close contact with upstream and custom compiled versions for use in the release process? I mean, if it were packages, then a new version of the libisofs package would likely result in a binNMU of the image packages. An updated version of Debian _services_ like apache or Alioth or dak would unlikely lead to binNMUs of any packages. > >My concern is the ability to replicate and derive the least possible > >from Debian resources like the install images. > > ACK, understood. > > >Concretely The Debian derivative PureOS is having trouble booting their > >homemade live image on some hardware, but boots fine on both Debian > >netinst image and Debian live image. Looking at the properly working > >images I noticed that the live image for stable was produced using > >newer-than-stable libisofs, > > Sorry, wrong. It was built using the standard xorriso and libisofs > versions in stretch. From the stretch-based VM used to build it: Whoops - you are right. My eyes are apparently too used to see equal versions in tracker.d.o as meaning unstable+testing, not the rare unstable+testing+stable that we have now. Sorry! > If the PureOS folks are having problems, they could ask on the > debian-cd list? Sure there is always the option to simply ask. I mentioned the concrete problem as an *example* of a more general concern: Whether or not it is even *possible* for anyone outside Debian to replicate the Debian product. We have Debian Policy governing (i.e. _documenting_ for outsiders) how we create packages, but apparently we have nothing governing the final procedures of how we create our images. > >and that the stable netinst image was produced using a > >never-in-Debian release of libisofs. > > Right, I'll give you that one. But there's *seriously* nothing special > there any more than what you'd find in any backport to jessie. I am talking about _avoiding_ uncertainty: Irrelevant to compare with other ways of introducing variability to a Debian system! > 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"... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature