 Shall we get started? Okay. Everybody, if as much as possible, please come sit up in front. I'd like to see your face. This will be as much as possible an open discussion. I'm going to try and prod you with questions and I hope you'll be willing to answer them. Building Debian from Debian is the name I gave for the talk. I don't know how great of a name it is, but there's all these tools in Debian that are used to create Debian installation. So they have some commonalities, some differences, and I'd like to see us move towards, if possible, using common tools, seeing where we're going to have to continue to differ and trying to get over always the, oh, I want full control over my tools and I don't want to have to wait for somebody else to fix something and then we spend all our time re-implementing things others have done as well or better. So the first question I have for you all is, what kind of representation do we have here? What sort of projects have you worked on? And if you'd please go ahead and pass the mic. Anybody? I'm the author of Fire and I'm sure I'm using Debootstrap, so I mainly rely on Debootstrap and the rest is done by my tool. I'm starting to work with the OpenMoco Debian group or team or whatever since this week. So what I want to do is do the kernels for the OpenMoco. Surely there's somebody else here. Are you awake yet? Okay. I'm just a user sometimes of Debootstrap and I'm interested in how Debian works also technically from inside on the package management system, so everything related with repositories here in your own set of packages interests me a lot. Okay. So maybe I'll just list off a few tools and if you have any experience developing and or using these tools, please raise your hand. I'll start off with the stuff I work on because why not? LTSP? Anybody? All right. SimpleCDD? DebianCD? Of course. Debian installer? Come on. I mean... Surely you've done it once. Zentools? Zentools? Yeah. UtilVserver? Okay. Debian Live? Okay. Libvert or Vertinst? I haven't really used it much, but... Okay. Peabilder? Uh-huh. All right. Estrute? Or Detrute? And Phi? Okay. So that's just kind of a list. I somewhat came up off the top of my head way back when. I'm sure there are other things that do similar type work. Maybe SystemImager, I guess. What was that? CowBuilder. Well, that's Peabilder, but yeah, yeah. Sure. So a lot of these tools have things in common. Many of them will often build a charoute. And most commonly that's done with like the bootstrap or CD bootstrap or something like that. So they initialize a charoute, right? And how many of you have worked with charoute? Yeah, there we go. Got to get some questions with everybody raising their hand. So they all initialize a charoute, and then usually the tools, they're not going to install all the packages you want. So you want to install extra packages inside the charoute, right? So these are common tasks across many of these tools. And most of them probably use the bootstrap or CD bootstrap. But for the extra package installation, there's probably a lot of variation as to how people go about it. I'm sure a lot of people do it manually with a lot of the tools. Some tools will provide something to say, well, also install this, and maybe you just do that by seeding it with the bootstrap or maybe you charoute into it and app can install it. But they all usually have some method for installing extra packages because a base Debian install is not... a core Debian install is not very interesting, right? So another thing some of the tools do is they maybe generate an app repository, such as Debian CD, you know, generates an app repository of some form. You stick it on a CD. And then frequently you're going to want to do some dependency resolution when you're generating that repository. Another common thing, kind of just looking at some of these tools, is some way of installing tasks or profiles, you know, a specific grouping of packages that are useful and that way the user doesn't have to specify, you know, every single package individually. You know, they can specify collections of packages with task cell or who knows what... any other mechanisms people know of? Task cell or anything else? Uh-huh, yeah, yeah. Dub tags. Okay. So it has its own mechanism for that. Yeah, okay. You got to get your packages somehow, right? So usually that means downloading them or making a mirror and then copying that somewhere. And there are a number of tools that can be useful for that. Some of them are just dynamic, you know, app proxies where you just point it at the mirror and if it doesn't have it, it goes and fetches it for you, then brings it back. There's also mirrors to do, like, a full-blown, you know, mirror for an architecture or maybe even the entire mirror in some cases, though those are getting pretty rare, I'm guessing. But you need some means to get all of these packages that you then install into a troup or maybe you install into an app repository or something. So one of the most commonly used tools for that is probably app itself, right? You just use app. You get the packages that way. Another common task is configuration. You know, you install a Roche root. You want some... You don't necessarily always want to use all the defaults for everything. So many of these systems have some ways to tweak certain packages, add configuration options. Maybe it's done through DevConf preceding. Maybe it's done through butchering the files manually. You know, maybe using CF Engine or Puppet, something like that. Another thing I was thinking of is some of them do an image generation of some form, whether it's generating an ISO image for the CD, a network block device, an NVD image that you then export over the network to boot, USB stick images, that sort of thing. So that's like just one big file that you then use to do something with. And another common technique is cloning. You know, you take a base system and through some means you make a copy of that system, maybe adjusting the few things that should vary. So these are some common needs that I just came up with. Does anybody have any suggestions for other ideas, other commonalities between tools? Or should I say does? Please. Bring up some other ideas. I think one important thing is that all the tools should be separated. So I think it's not very good to have a tool that's building the change route, doing the customization and creating an image or because often people like to have only one part of this functionality and like the Unix philosophy, we should have a separate command for each task. I've got an uncommonality, I think, which is cross-installing as opposed to just installing, which I guess anybody else really wants to do apart from the embedded people. And Debian does an appalling job. I mean, there's nothing at all in the system that lets you move the root of all the maintainer scripts before running them apart from charooting. So you have to have everything in the charoot that you need to install everything rather than just the stuff that you actually wanted to install. So you have to install a whole pile of other packages. And most of that stuff is just fiddling them out with files and registering things and boring stuff that doesn't need to be done by the target device. So I'd really like to see changes made to support that, but that's a really big deal. I think it's a big change to make it work. I've got one question. Does the bootstrap currently support creating the first change route on a different architecture? Does this work? Yes, but you have to run all the maintainer scripts. The second stage you have to do on the device, essentially, or under QEMU or something. All right. The fair amount of work I've done this conference was using QEMU to generate a cross-architecture LTSP setup, which only so far seems to work on RMEO. So yeah, that's another topic. For people who haven't thought about this before, the main thing, as well as being able to tell all your scripts to run over here, or at least on the files over there, separating the install time and run time, both separating the dependencies so that you know which things you needed for installing the files versus actually at run time when the package is running will be really useful and then you could tell. And actually separating the script into those two parts as well. So there's a maintainer, install the file script and then a maintainer actually run on the system because this really does need to run on the actual box when it finally boots, which I guess we could do. I mean, it would just be another stage in all those scripts and pre-things and post-things. Okay. So some of the common kind of lower-level tools maybe go for another round of hands here. Debootstrap or CDbootstrap? Anybody? Yeah, yeah, yeah. Aptfdparchive? Yeah. Dac? No. Reprepro? Yeah, yeah, yeah. Okay. Aprox? Appcashor? Appproxy? All those? All right, great. Wget, curl, rsync. All right. Shell? Yeah, yeah, there we go. So where are we going to go with all this stuff? We're doing all these things. We have all this code. Some of it's disturbingly similar, but different in its own ways. I remember when I first looked at the ZenTools script, I'm like, this looks just like LTSP, but all the variable names are different. Or WNLive, you know, same kind of a thing. It's like, a lot of them have this layered structure where you load plugins as you go and you build something. And it seems like a lot of code duplication. Like kernel selection was one I noticed. Remarkable similarities in code when you're picking a generic kernel to install, you know, some architectures. There really isn't a generic kernel. A lot of architectures there are. Sometimes you can just tack on the D-package architecture name. Sometimes you have to know, oh, well, it's 486 or, you know, coming up with that stuff. So... Just one thing. There's multi-strap, as well as debut-strap and CD-boot-strap. There's now multi-strap for anyone who hasn't discovered the fundamental difference being that you can point it to several repositories at once and just get apt to work out what you need. Which is really, really useful. Sure. Well, gathered all your people here. I would say that if I look at the list of the tools, there are a lot of tools that are not general purpose, but for a really specific environment like the Xen tools. They're only for setting up the Xen environment. So sure, it's just an exchange-root environment with some additional Xen-specific configuration files. I think the same applies to LTSP and maybe things like P-Builder is very general and I would guess FI is also one of the really general things. Sure. But they all still do almost identical things along the way. I mean, they're general tasks. I mean, if you look at it, I bet a bulk of the code wouldn't really be all that FI-specific or LTSP-specific or any of that. That'd be a small part of what they're actually doing. Perhaps I'm wrong. But from the few ones I've looked at, they look pretty similar. Well, so... Sounds like you've actually had a look at the code base. Do you think you could take two of those and turn them into the same script? I mean, how much work is that? Or is... Does it need to be split like it says, turned into three chunks? Right. And then you make those, split it by level and then you really can make something. I guess the two maintainers of whoever maintains these things need to say, well, yeah, okay, maybe we should just have one. Right. Well, it's almost more of a political decision than a technical one. I mean, there's work to be done. People have to re-implement things. There'll be regressions, whatever. They'll have to come up with ways to do it. But technically, it's just some work and people can go of their complete control over their own tool. That's my guess on it. But... I think it was last year when Michael Prokop, who does the Grimel live CD, I think you all know this. It's a Knopix-like live CD for Cis Edmonds. And in the past he was doing the next version of his ISO image by Lupec mount, his ISO image, change root into it and then do manual changes to the file system, upgrading to new packages and then all recreating the new ISO image. And then I showed him Fi and I think it took two months for him to work a little bit on it and now he's creating his ISO image always from scratch by just writing some Fi configuration files and he can also use his scripts to do some customization on this change root environment and also creating the ISO image is done with Fi and his scripts. So maybe if other people like to have a look at it, can I also create my special change root environment with some additional config files? Yeah, you can just contact me or the file mailing list and have a try. Yeah, I've also I've before, just kind of as an experiment, I've used LTSP to generate a bootable live CD image, you know. It's a same type of technology. Those both share read-only root file system where you somehow overlay some place to write the stuff you need to write. But yeah, so even as a proof of concept, it's not hard to do cross-tool purposes or emulate the functionality of other tools. And I think that's one of the big points with the move towards libvert and all that stuff too is that we've got all these, I think it supports KVM, Zen, Chemew and a handful of others if I'm not mistaken. So that's a good example of just moving towards one tool that can really handle all of these things which are virtually identical. But yeah. Well, so where next? Any people? I don't know. Debian boots pretty specifically Debian installer related. I suppose, yeah. Yeah, would it be useful to have yet another mailing list to discuss these sort of things? I sort of thought of it in the once Debian custom now blends sort of infrastructure using it less as a customization for a user experience and more the customization for a specific a specific implementation instance. Would you like... Is there a need for having a common list? So we had a need for this simple CDD discussion obviously and perhaps we might merge it with FI but there is a FI mailing list and you don't need all this. In principle, I think every specific tool has its specific list which in turn means that these two will never can cooperate which is other. But what I learned from this blends effort with the project which have much in common do not discuss on the common list that I always have to discuss with several lists even its concerns very general things but people do not really like this general list. So I kind of missed the beginning of this. Does everybody actually use Debootstrap and then wrap that in various messing about? Is that how FAI and CDD and so on work? Sort of. I think most of them probably do at least have that common foundation though I think there are definitely some which lean toward CDD bootstrap and some which use Debootstrap and now we have a lot of people who use Debootstrap but I think Debootstrap and now we have got multi-strap I guess so I think we used separate install script for Debootstrap to start with but various things broke and I think it was easier to give up and do something else than it was to carry on with that I think is where we currently are and the lack of an ability to point it at multiple repositories was the biggest thing but I guess we could teach what we ended up doing in the end was just multi-strap just basically gives a list to apt and says go and get these things and then that's right the other important bit is that you don't end up with all the devs in the image you've created which always seem to be a rather shitty feature of Debootstrap it's twice as big as it needs to be and having unpacked everything it then goes and unpacks them again this time telling the package about it and just go it doesn't need to do that so we actually unpack them and do everything apart from the actual configuration step which is the only bit we couldn't do locally gone all vague so yeah so well we didn't object to the tool it just didn't really work very well maybe we should just but I think I didn't write it you need Neil and he's not here my understanding is that the multi-strap approach is very different it's not it's just a change of the scripts I have no idea whether it worked for everyone else maybe I guess maybe the way to proceed is pretty much for people maintaining the tools to talk to each other one by one to kind of go could we do the same thing or not with you know how much difference is there actually between each pair I'm not sure that sitting here today we can I have no idea what the rest of you do I've never looked we started by asking so what do you do yeah well I think I just told you so there's two tools as well as multi-strap for doing grip installations there's M Sandbox for doing crush installations which doesn't does an awful lot of jiggery-pokery to basically because we can't run the maintainer scripts but we need to have an image configured enough that it will actually boot we actually just go and basically take a load of code out of all the maintainer scripts not in any organized way just to kind of manually go oh we need to do this and we need to do that and we need to do the other and put them together in a big scripty thing so it's vile but because there's no infrastructure there's no metadata in Debian that allows which parts of a maintainer script can be run even though it's all most of it's auto-generated by debhelper so it could be auto-generated differently and it would do what we wanted but because basically there's no scheme for it at all we just have to do horrible hackery so yes we'd be pleased to throw it all away it's hopeless and unmaintainable and rubbish but you know it does work so yeah I'm pretty happy to use those tools if any of it works please tell us how we should be doing it differently with lack of much direction I don't know if we just want to kind of wrap up and maybe have some informal one-on-one discussion or something along those lines I mean I've long been meaning to look at phi and I look at it briefly and then I go on to other things so I know it's hard to step out of what you're working on and look at somebody else's and take the time to do that but I think it would benefit all of us to do a little bit of that so that's I don't know I might come away from here trying to make a commitment to look at some of these other tools in greater depth I was thinking maybe we could sketch out like a design of how the ultimate image creation tool would work sure I think so I don't know so what I was thinking was I went to Joey Hess's DevHelper 7 talk and I was really inspired by the override stuff and I was thinking maybe that could be applied to this sort of situation yeah so maybe to briefly describe what that was like or just a paraphrase what the override stuff was so normally DevHelper just automatically figures out based on the upstream source what you want to do and then if it doesn't know you can't figure it out then you can create an override underscore whatever the step is rule and then what that rule is supposed to do when DevHelper can't figure it out so in that way it embeds all the commonalities in DevHelper and then all the differences are just in your rules file I think well in file we have something similar in file when building change route environments we call it file deer install and this is a sequence of tasks we execute so sure the first task is calling the bootstrap and in file it's also possible to extend or replace each task we call it hooks or you can also say plugins it's similar because you can override or extend a certain task with some other script or functionality I think LTSP also has a plugin system where you can have a local administrator plugin or a plugin installed by another package that overrides the defaults so to some degree maybe we have that but it might be hard to represent it as DevHelper does but that would be a nice goal to evaluate whether this is possible you need a list of all the things that all the various installers do to work out what the ultimate one has to support and then some idea of the difficult corner cases the bits you can't run because it's not the right architecture or whatever other people's problems are and and then if you can think of a design that does that it seems to me the problem is solved apart from writing the code but the point about the DH is that you write down the differences from what you normally do as opposed to writing down everything you do which I guess might make sense in this context although writing down all the things you need to do and I suppose it's more configurable, it's more automatic if you only write down the differences isn't it because you can guess better are we on time? alright so I think the next step with this discussion is maybe someone whoever has time look at the archive and see which one depends on the bootstrap or see the bootstrap and just review the differences and the commonalities there and see which one does most of it anybody want to do AppCache R depends on the bootstrap? get a list I think that's alright AppCache R depends on the bootstrap yeah a lot more than we mentioned okay that's more than we mentioned so far some obvious glaring omissions so far no because I don't know what some of these are rootstrap sbid box Live Helper LTSP server PiUpArts QMU builder most of these were mentioned in somewhere in other five server utility servers and tools detrude there's one tool called rootstrap I didn't know Garneti instance debutstrap seems to be a special version of debutstrap and mostly are the virtualization or change through tools AutoPackageTask Xen LVM Embedded RootFS that's a pretty good list I guess that handles more the charoot cases there's another one deburf it generates in-it-rds in-it-rds image generation charoot creation probably extra packages category yeah we could categorize these with deb tags I've got one question in file we also need something like apt cacher, apt proxy and I get very different replies to what people are using I'm using sometimes apt proxy I have mostly a complete mirror of the major architecture on my machine I heard there's apt cacher next generation or something else which is the one tool that works really good I didn't really play many expertise except last time I looked at this a while ago and everyone said that proxy shite doesn't work properly I recently put apt cacher in and it's brilliant and I should have done it years ago it is fucking marvellous so I have no complaints at all but I don't know if there's corner cases where it's problematic I have used in the past apt proxy and eventually when it got rewritten in Python the memory usage skyrocketed and then and I looked at apt cacher years ago and something about it just made me nervous and then I've been using a proxy but I haven't looked at either apt cacher or apt proxy in any recent probably four years but I'm on a proxy loyalist here but yeah any more exciting new ideas about how we can cooperate, collaborate or poke each other in the eyes poke everyone in the eye won't move on we're kind of at the we need a design document stage really because I have no idea most of us have no idea what all the others do really in any detail to work out what the commonality is beyond debut strap so create the mailing list get on it maybe wikipace sounds good yeah is anybody excited to work on this? some interest that's where I started this talk I think we're very happy to use common infrastructure if it exists I don't know how much we could spend some time on it on our our corner as it were as I say most of us issue is really major debut in infrastructure changes it doesn't matter it's a relatively minor detail as it stands we're just working around the lack of infrastructure that's really a separate problem but you know the stuff we have got that's different very happy to merge with something so somebody want to create a wiki page now just initialize it with some empty content you could cut and paste the talk or whatever stick it on a wiki page it's going to be the first to do it we'll have 10 I don't have a computer right now I'm thinking we get it done now so that we go away and we got something to hit at a later date not any comments on IRC or anything right okay I called this spot building Debian from Debian we started we can always rename it MetaDebian installer cool so sounds good and then thank you all for coming at this wee hour in the morning and uh yeah yeah there's that too