 The title of this talk actually comes from thinking about the Death and Grandfather's group and the fact that that helper has been around for 11 years or something like that. I think I'm going to wait a couple of minutes until I get people a little bit longer and trickle them because I do have as many people here as possible just to, you know, with doctor names or votes and so on and so forth. This one I'm going to talk about is changes that have been made to Def Conk over the past about a year and a half. In terms of all of this, sort of unexpectedly, we started making some larger changes to that helper that have happened in the past seven or eight years of its existence. And one other thing, if I say Def Conk accidentally during this talk, I mean Def Helper and just for other people's information, when I referred to Def Recade, Def Helper yesterday I was referring to Def Conk. I do tend to get confused. I have no plans to Def Recade Def Helper at this time. So you should all be familiar with this, I hope. This is pretty much how your W to this file has looked for 10 years or so. Now, what happened to me last year as I was looking at this and I realized, hey, there's some code duplication here. So it's re-factoring. And so the idea here is that DH, Binary Arch, just runs everything that your Binary Arch company will do. So that's simple enough to write. And that's DH. You went into Def Helper 7.0 back in last year. And when you use DH for an entire rules volume, come up with something like this. So for every target, for every standard target, you run DH. And you just give it the name of the target. Now you might ask, what about dependencies between targets? What happens if I run the Binary Arch target and I haven't run build yet? And the answer to that is that DH is intelligent and tries to figure out behind your back basically what you've already done and what it needs to do next, even without targets in there. Now if you want to, the targets in there, you could stamp files and all that kind of thing like you've had before. But the fact is you don't need any of them. And the nice thing about that is that we can notice, hey, there's code duplication that's fine. Let's refactor it. And so if you're not familiar with make pattern rules, what this does is the percent up here stands for any of the rules in that file. The fluctuation here stands for the name of the rule. So basically if we run the variables build, it's going to run DH build. And run the variables binary, run the DH binary, et cetera. So with that change, some interesting changes began to happen to the length of the rule styles of Debbie. And unfortunately, I didn't collect historical data here. So it's just the current data. And to understand this graph, going up, we have the percentage of rule styles given length. But along the side, we have the length of the rule styles starting at five over here, which you can't read. And going up to a hundred and more lines. Now the red line here is CDVS, which as you can see is really good at making the rule style the under five lines, maybe ten lines, something like that, and the trailer's off. Down. And if you look at traditional death helper, which is the black line here, we see that it's really good at optimizing rule styles around 40 lines, 55 lines, something like that. And then sort of trails down and it almost parallels the length of other, which is the smaller set of packages that don't use death helper or anything else than just going all by hand. And those tend to be longer to the long end. Interesting that it can be shorter for the short end. And there's that interesting little thump over here, which I suspect is things that use Yawter or something like that. And I didn't bother to fill those out. So there might be some interesting, weird short rule styles out there that I didn't grab for properly. So of course DH is the remainder of the graph. There's a really tall hump there. 45%, almost 50%, for those files that use DH, walk in somewhere between 15 and 20 lines. And then there's a previous hump, 15%, or so, actually, you know, somewhere in that area, or two lines to five to 10 lines. Now there's a reason for the two pumps. And that is that if you go back, you've got two different variants of the rule style that can use DH. So that's simple enough to understand. Okay. This is market share of various tools, after DH's been around for a year or so. As you can see, it's gotten almost 10% of use. CVS, I forget what it was at last year, it was somewhere around 25%. I think I probably eroded it a small amount, but it's probably also gained some more followers. And that helped, of course, since most of the rest, there is that 3% of weirdos. So what does DH can do? It's really easy to figure out what DH is going to do, exactly which commands it's going to run, and the exact order that it's going to run them in, just tell it to run the command to do no act. You have to run the system inside a actual source package, or it's going to go clean out of you. But it's useful to see what it actually does. And when we look at what it does, we see these DH auto commands, which you might not be familiar with, or you might be. These have the added to depth helper to support DH. So what do these things do? Well, they basically figure out what they need to do to build the given source package, and magically do it. This is a short answer. So if we have an auto prompt using source package, they'll run the figure, and then they'll run the name. And then when they want to test it, well, some of these packages may test, some of these may check, and they magically somehow figure out which target to run, and run it. And if there's an error, or an error, which is sort of tricky to make, actually, it's impossible, but we did figure out what to do. Now, if you have a pipeline package, they'll do something completely different like this. And there is currently, I think, no generalized test suite for pipeline. So they don't run the test set. There's no configuration. They just want to set it up high, and they pass it various things. And I think I'm going to see my cleaner. I think that's an open office, but it's actually in the source. Okay, so for PURL, they might do something like this, or they might do something completely different. And PURL has lots of different ways to build. You know, there's no way to do that. But they'll do something that is probably the right thing that it might not be. So the interesting thing about DH Auto is it's designed to work for a common case, a case like this. You need to build a package by running the figure and running the name. It's been like that forever. These tools can handle that pretty well. What about something like this? You need to build the package, pass it, arbitrary arguments to configure. When you're a mate, you have to do some other weird thing. You obviously can't use DH Builder. This is a good new idea how to do it. So how do we handle this case? Here's one way. You can say, let's override the DH Auto Configure. And when we do, we'll pass in this without pushing the same parameter. Let's override the DH Auto Build. And when we do, we won't even run the DH Auto Build command. We'll just run whatever name commands we want. And the thing you need to realize about this is these override targets are run by DH Build, and it sort of figures out behind your back, hey, your rule spot has these override targets in it. I'll run them. And that's the right targets when in February of this year. Here's some more examples of it. So there's, you know, these handle, you can handle lots of the standard cases that you may be familiar with, like needing to make a file, set UID, DH fix firms, of course, clears all the accept-by-dits, just to make sure when you're treated by accident. So you can override that, run DH fix firms as normal, and then go back in and make something safe that you need to make to. If you need, you know, there's other examples. Passing various options for commands is fairly common. The under the bottom, I put one in. I remember that at one point we would see something like this because it was going to not work on some architectures. And they wanted to see the test suite results even though they knew it was going to fail. So you can basically, I think these overrides are pretty powerful. They let you do all kinds of configuration and customization in your rules file and still use DH. Here's a completely variable example for the 80-week package. This is the complete rules file. And you can see that there's really not too much customization needed here. There's a little bit of weirdness around how to clean up. I don't want to compress files in the HTML directory because it's breaking some links. And I've passed some weirdness from the group. But the thing that I like about this is when you look at the rules file, you see exactly how this thing is different from every other package out there really quickly. There's nothing in the rules file except for the differences, which I think is really handy to just say, oh, three differences. Okay, I know what they are. And this is a graph of the frequency that various commands are overridden currently in the archive. So I'm happy about this graph because all of these down here are the DH auto commands, which are basically designed from beginning to be overridden because I know that I obviously can't figure out how to handle these cases in all cases. So they're frequently overridden. And then, you know, there's things like DH install change logs that people frequently need to pass parameters to. So it's pretty common to overwrite that. I'm not really sure why so many people overwrite DH install. Maybe they want to pass to the weird parameters it has. So that's a pretty, one other thing I like about this is I can now graph the archive and figure out when the developer isn't working for people, when they have to pass in weird parameters and things like that and just get some easy idea of it just by looking at the overrides. So that's helpful for me to make the developer better later. So when I was making this DH thing, I did run into a whole problem, which is that we have three programs that handle Python. Now, one of them is actually that developer is completely, you know, obsolete. But there are the other two, DH Plastic Board and DH Placentral. And there's window consensus, which one we use, but I did need to make one be used by default because otherwise I wouldn't store Python packages, which would seem like a really good design choice. And I arbitrarily chose the DH Plastic Board, but that also didn't seem like a really good design choice. So, here's a way to, here's my question. Now, you could do a video provide, and I think that's perfectly valid way to do it. The overrides actually were developed after the second system, which is just saying, run the build, but run it with Python Central. And how does that work? It's called a sequence add-on. And it, I would develop a pretty soon after I developed the original DH before I did overrides. So, here's some of the sequence add-ons that are available now. I don't even know what some of these do. For example, root bash completion. I'm not really sure I can answer some developer command to your command sequence that installs bash completion files. The Haskell desk description is very complicated. The most interesting one there is probably with bolt. And I think there probably were in the archive. I didn't believe it was a good graph. The key point, though, is that all of these, with the exception of with Python Central, are add-ons. They're not even included in developer. Somebody's gone off and written them. And that's encouraged. And it's as easy as writing a very short plural module. Something like this. What this does is this is the actual implementation of with Python Central and that helper. And all it says is on where DH plural is, and the sequence that you're going to run. And it's in there, put in DH PyCentral, and then just paint out DH PySupport. And this makes sure that DH PyCentral is in a reasonable place. It also makes sure that even if DH PySupport isn't available for some reason, we still get PyCentral. Here's a really complicated example from Haskell Demscripts, which adds all kinds of weird commands to various points in the sequence that DH Auto runs. And what I really like is they go before DH Compress, they add DH Compress dash X dot Haddock, and then they remove DH Compress, which apparently works, but that's the kind of thing that I think might break. And though I guess I'll have to keep it working now, I know about it. So here's the usage pattern for DH sequence add-ons. And I thought this was really interesting, especially since the Quilt one has only been around for like two months or something like that. There's obviously a lot of demand out there from people in Debian to be able to use Quilt in their packages easily. And the nice thing about the Quilt one is you just say with Quilt, and you automatically get patching and un-patching of using Quilt, no other modification of the whole style necessary. And again, that's implemented completely without any changes to depth helper. So the next interesting thing, yeah, they just keep coming, was uploaded during depth comp after significant testing, and it's called Build System Classes. And this is actually interesting to me because it's an enormous modification of that helper that I didn't write. It was written by the store called Modestus Vinius, who may be in the audience, but I doubt it. And I don't know how to pronounce his name. Does anyone know how to pronounce his name? Because when I see that name, I can't help but think of Modify. Anyway, the Build System Classes are basically what you get from CDDS, except they're now in Dev Helper, right? So you can ask the DH Auto commands to list which Build Systems they know about. And this is the current complete list. You know, Autocon, various cool things, make files, Python, CMake, Ant, maybe Scon, Smorrow. No? And okay, the interesting thing about this list is it has to be in this order where things break horribly. And the way this works is when any of the Autocon commands go to build a package now, they say, well, which Build System do I use? They figure it out by looking at which files you have in your source package, and those are all the files that are listed in parentheses. So if there's a configure script, it's probably an Autocon package. If there's a Build.xml, it's probably an Ant package. If there's both, well, we'll assume it's an Autocon package, because otherwise you might break some unknown number of packages when we add Ant support, which was done in an afternoon about a week ago. Now the problem, of course, with just guessing, is that you sometimes guess wrong. So this does let you override it, which can be really helpful for things like Perl Build, where there can be a Build.xml file, there can also be a Make.xml file that will guess that it's a Maker package, and possibly do the wrong thing. So the Perl Group, I hope, will start using this whenever they know it's a Perl Build, or a Module Build package. The other nice thing about Build System support is Modesta's went in and taught all the DH Auto commands how to build from a different source directory in the top level directory, and how to build into a different build directory, assuming that the Build System supports it. Of course, Autocon does things like Perl Build, and that kind of thing don't. But if it is supported, you can build in a different directory and just nuke it easily at the end, like you might be familiar with doing without using Dev Helper. So third-party Build Systems can be added by writing another Perl Module, and I'm happy with people doing that, especially if it's something really weird that I don't want to maintain. That would be great. The only problem is that Dev Helper will not automatically go off and use your Build System unless you do pass this Build System switch. Otherwise, somebody could upload a Build System that just broke everything, and I really don't want that to happen. So if you want it to be enabled by default, you do have to contribute it to me, and I'll figure out which order to check for it and things like that. Here's an example of a made-up Build System, FooConfig. It works something like Autocon, and this would be the complete implementation of that Build System. So all we have to do is the CheckAutoBillableSubroutine, or actually Method, this is object-oriented code, goes in and checks to see if there's a FooConfig file that's executable. And if so, when we're configuring in DH Autoconfigure, it just runs it, passes it parameters, and that's it. Now you might ask what happens for actually building the package? What happens for cleaning the package or testing? The answer for that is, this is inheriting from the make-file class. This is object-oriented, blah, blah, blah. So it works, apparently. You can just inherit the make-file, and then when you run Build, it will run, it will build using the make-file that FooConfig presumably creates. So you put all this together and you get something that is not entirely like DevAlper used to be, with all these weird switches and overrides and stuff like that. And it might look something like this as I really hope not, because this is pretty over-the-top amount of stuff being used. But I do hope that these things will make DevAlper easier for people to use and result in shorter and easier to understand rules, files, and et cetera. And with that, I'll thank you for using DevAlper and open it up for questions. Enrico. One thing that I find quite interesting is that in the end, DevAlper is doing most of the work, but it gets invoked a lot of time during the build process, and it always has to figure out where is stuff, what can it do, what it shouldn't, and so on. So I wonder, I mean, it feels like to me, we are pretty near the point where you can do, like, instead of a hash bank make, do hash bank developer, and then it figures out what's in Debian slash at the beginning, and then just do that little bit, which would make it insanely faster in theory, but I don't know if that's any sane thing. I think that you're right that we're pretty near the point that it would be a pretty easy modification to do that. Of course, policy wouldn't allow you to do that, because Debian rules does have to be a make file, no matter how perverted and short it is, apparently. I don't know if it would really make it significantly faster, because DevAlper was, after all, written 11 years ago for machines that were a lot slower and does have a lot of wacky little optimizations in it to make it start up quickly and figure out where it's at fairly quickly. So you might save a couple of seconds, and it might be a shorter and more comprehensible rules file, but then again, I think that the way that we have overrides in here does sort of use make in a fairly sane way. It's a useful use of make. If DevAlper were up at the top, we'd have to have some other way of doing these overrides, and that would involve re-implementing make, so. Any others? A DevAlper 7 module for doing Java some Java packaging stuff. And a couple of questions about it. With these overrides, can you override things which have been added through sequence add-ons? Okay, yes, you can. Using the overrides here, any command that DH happens to run, it will first go off and look to see if there's an override, and if so, it'll run the override instead. So yes, you can do that. Okay, so when you're adding things into the sequence, you say add after DH file, and then you say remove DH Python support. So other part of my question is, can you do double dash with, quilt double dash with, and so on and so on, and include several different third-party add-ons? Okay, so you're, oh yes, yes, of course you can. You can use with as many times as you can. What if you, the person writing the second one that gets included is trying to put something after DH Perl, and for whatever reason, the first one you include has removed DH Perl? Well, then obviously you have a problem, and those two people need to sort that out. I can't really fix that problem without coming up with some much smarter way of figuring out where things go in the sequence, you know, dependency-based or something like that. Hopefully that won't come up that often. I think that the need to actually remove a command should be pretty rare, unless two packages are conflicting like these two aren't. In that case, I think they have a problem of their own making. And the last thing was, I've got a sort of absolutely minimal Java build system as part of the tools for this, which basically says I've got a bunch of Java files, please put them in a jar, and I just call that, I've added it insert after DH Auto build, and a file, it'll do something otherwise it won't. And is there any reason why I should write it as a build system class, and which then people have to explicitly use, rather than just saying with Java helper, and then it just does it? Well, I think it's up to you which one makes the most sense to use in a given case. The build system classes are useful in that you can use them even if someone isn't using DH. It's possible if you don't like DH, you obviously don't have to use it, but you still might want to use DH Auto build in your rules file just to let it take care of building for you, and so it's clear what's happening. And in that case, if you have a build system, then DH Auto build will actually know how to handle it. If you're using with to add something to the DH command sequence, then that won't happen. So that might be one reason, but it really is up to you which one makes sense, and there is a bit of overlap, clearly. All right. I see here that in Lenny, we currently have DevHelper 7015. So during the squeeze release cycle and development cycle, should we avoid using Overrise because they're not in Lenny, or is this going to be added to a point released to Lenny or something like that? Well, I have given all the versions that you need, and of course you do need to make sure you build dependent on those versions if you use one of these new features. As always, one of the new features added to DevHelper, people do wonder about this, and I generally hope that someone will backport it, but I can't really do anything more than hope or possibly backport it myself, but I'm not going to try to get it into stable at this point. So it's sort of up to you whether you want to use these new features or way to release cycle to do so. I'm personally using them in my packages because I think the minor pain of having a backport DevHelper more than makes up for, I mean it's more than made up for by actually being able to use new features when they come out. Well, already we can at least use the... You can already use the DH stuff. The DH stuff and the sequence add-ons at least, right? The sequence add-ons, of course you can't use sequence add-ons that have been added to unstable in another package. You also have to when you use a sequence add-on figure out what package is providing that and depend on that package. The make file overwrite thing is parsed by Perl, I guess. So that would mean that you have to be a bit careful about how to specify them? No. It turns out the way we figure out that there are overrides in the make file is by asking make to list all the targets that are provided by the make file. Now, make doesn't have a really elegant way to do this. It's possible that its output might change, but any valid make file will work. You could even... I'm not sure if you could include another file and use overrides in that one if make would tell that those targets are available or not, I'd have to check. But you can use all kinds of make constructs in here. There's no parsing of the skilling one that is fragile or anything like that. That actually surprises me because I was told for a very long time that the reason we don't have binary arcs is that was it possible to do? Yeah, well, it's apparently not. It's not pretty to do. It'd be nice if make just had a really easy way to test if a rule was in a file, but it's not there. I can show you the code if you're interested. It involves running make in debug mode and parsing its debug mode output. Right. Anybody else? Is it possible to use DH for packages that built multiple binary packages with different configure options? That's a good question. Currently, if you want to do that you have to manually override DH configure and DH auto build and run those yourself and DH auto install and install it in yourself probably. There was a bug report filed yesterday with some suggestions in this here. I don't think it actually completely covers that case though. So if you're doing something really out of the ordinary like that, well, potentially a little bit out of the ordinary like that, you do have to override it and do it by hand. But I think that's really okay because you'll end up with a rules file that will pretty clearly show what you've had to do and it's probably not any worse than beforehand, I hope. Do you expect DH to kill off CDBS? Good question. Don't know. Well, I guess I'll look at the graph in a year or so and see if people are just switching from Dev Helper to CDBS or if they're switching from CDBS to DH or what. Personally, I would prefer that when I edit a rules file, it use Dev Helper or DH or something like this and not CDBS or IATA or something like that, but I'm not going to try to dictate to the project what they should do. I'm just going to provide the tool and if you want to use it, there it is. My question to CDBS one too. No, no, go ahead. The abstract specifically says how it can be better than CDBS. I haven't really addressed that, have I? Exactly what you think the differences are and why you don't like CDBS, etc. So, this is one way of looking at Dev Helper and DH and CDBS and comparing them and what I like to do is just look at what I think of as the visible surface area of a command. Now, I realize this slide is really scary, especially if you're in the back of the room and it's sort of meant to be. This is all the things that you might need to know if you're using Dev Helper in a rules file. You have to know all these strings, what they do, when to use them, etc. Now, of course, we have some long options, we have some short options, we have some environment variables, we have some package control files in the Debian directory, and then we have some commands. And that's the interface to Dev Helper, right? Here's the interface to CDBS. Now you have to be about here to see it, right? We have some make files, fragments that you need to include. You might not need to include all of these, but most of them are things you might need. We have some options, about 150, I don't know, a lot that you might want to use at some point if you can figure out what they do, if they're documented, if they don't change what they do tomorrow. Some of these are semi-internal-ish, a few of them are probably completely wrong and you would never want to use them, but it's really hard to tell. And some of them are very well documented in the manual. And then down here at the bottom you have a couple of minor changes that you might want to make to your rules file to run other commands and things like that. So when we look at DH, this is a visible surface area. Of course this is added on top of Dev Helper, but then so again so is CDBS. It's 153 items plus the 100 odd items from Dev Helper that you might want to need to know because you can mix and match. Now in DH we're adding 12 items. We have overrides, we have a few commands, we have a few options. So I think it's really elegant that I was able to do it with this little, if I say so myself, but I was able to do it with this few addition to the visible surface area. So that's personally why I think the DH is better than CDBS. It's up to you to decide. I think Jonas is going to have a comment now. I must say we looked a bit on that specific one together. Yeah, I did a few events. And actually I must say, could you switch back to the ugly one? How completely wrong is this? I did spot one of them in the middle, around the middle somewhere. I don't remember which one it was. That Dev Helper does not support. Well, yeah, that's true. Yeah, yeah, CDBS has an option that Dev Helper does not support. They're okay? Yes. Yeah. There are options in here. Yeah, that's right. That's the auto update. There are options. The one that is illegal to use. Right. I wonder why Dev Helper doesn't support that. Is that really the only thing that CDBS does that Dev Helper doesn't support? Because if so, gosh, you've got a big interface for that one thing. It takes time. So, you know, when I think about this, I like to think of this. Now, when you're building a ship in a bottle, you need all kinds of specialized little tools to reach in through the neck of the bottle and lift the sails up and then attach the rigging. And, you know, you need a little tool to adjust that cannon just right and all these things. And there they are, right? Now, granted, we are building, we could say, well, there's lots of tools here, but the fact is, this is a whole workshop of tools that's out there for you to do whatever you want to mash around with. These things are all reaching in through the neck of the bottle of environment variables, settings, and making changes to that ship in there. And sure, it looks really pretty when you're done with it, but, gosh, it's really complicated to get there. So, Colin. So, you've just checked. You've been working in Dev Helper for about 12 years now, I think. And, you know, free software development is always kind of incremental and you do what's needed at the time. But I'm interested to know if you have a sort of end goal and slice. Are you ever going to stop and work in something else? Or are you going to declare Dev Helper done, or is it something that you see as always evolving to make the needs of Dev in? You know, the end goal for Dev Helper was actually accomplished like seven years ago. The end goal was, let's make the rules files a little bit prettier and easier to understand, hopefully, and, you know, easier to make broad changes to large swaths of packages by changing one thing instead of having to modify a lot of rules files. And that was accomplished, and I thought I was done. And then in the past year and a half, I thought, well, gosh, there's a CDBS thing and it's really showing that there's a need to do something else. So thank you, Jonas, for that. Thank you very much for showing that there's a need and demonstrating it in a way that made me actually have to do something. Am I going to continue to be interested in this? I don't know. Somehow it has remained interesting. I think it's because working with Dev Helper is a great way to completely destroy Debian by accident. And that's the kind of thing that can be interesting. I actually had to do full distribution regression testing to test the build systems option, which I've never done when I've added something to Dev Helper before, believe it or not. And I did find one or two packages that were broken by the new system, but I actually thought it was worth putting it in and just filing a couple of bugs. And unfortunately, one problem with the new build systems and with DH is that they have a lot of very specific things encoded in them, like the order in which you run commands. And if you change that order, you can break untold numbers of packages now. So I have all kinds of ways to break Debian by accident now. So maybe I'll be interested in it for another 10 years. Who knows? Well, I think the decision what will be used, Dev Helper or the CDBS will be done by the documentation. And it is not really hard to have a better documentation than CDBS. I was always fighting with it. And I'm really, really happy that I see now these very easy rules files. Well, as far as the documentation goes, there is a man page for DH. Can you see that in the back? I'm going to get a bit bigger. There is a man page and it has some little examples at the bottom, which I basically just reused in this talk. And I think that if you read that, you pretty much understand enough of it to use it. Or if you just read a couple of rules files, you probably understand it. So I hope that that's enough. If not, maybe I should turn this talk into a bit more documentation. Just a small comment about documentation. When I read about your new DH work last year, I said, oh, cool. I tried to actually migrate my small, really small package to it. And I couldn't find anything similar to how to, really, really simple. You have to do this. This is the equivalent of this. For example, patching. I'm still trying to find out how to do the patching. Are you talking about quilt patching or just generic patching? I'm applying patches to the source of the... By hand in the rules file, basically. Yeah. And I mean, the way you would do that is you would probably go into your rules file and make an actual build rule and a clean rule of your own. Or you could override DH Auto Build and DH Auto Clean and put the patching in before that, but it's a little... I don't know if you'd want to do that. You'd probably just go back to the older style rules file that has all the targets explicitly in there and then do the patching by hand that way. I think that would be the way to go. I think it's okay to not use this really short stuff if your rules file is doing something a little bit out of the ordinary, which patching sort of is because there's no established way to do it except for using quilt. Of course, if you switch to using quilt, it's very easy. You say with quilt and then you put your patches in the right place and it all works. Now, as far as your broader point about the documentation, yeah, I think it'd be great if somebody wrote a little tutorial. Here's your typical rules file and some things in it, and here's how it looks when you convert it over to DebHolper V7 and DH and all the other new things. Yeah, or just a wiki page with a list of packages using DebHolper. Yeah, sure. Yeah, that's a good idea. That will be great. I have a list right here, so yeah. Thanks. Well, now that we seem to be converging a bit on quilt for patching, wouldn't it be possible to just check for a Debian Patches series file and then assume it's quilt and then try to do that? Because otherwise, that seemed to be the most overridden thing. Right. Is there any plans for that? Well, it is the most used with flag. On the other hand, I like the fact that there were no changes made to DebHolper to implement that, and I'm hoping that we get a source format that actually natively supports quilt that's actually supported in the archive. So I'm sort of reluctant to make DebHolper have some kind of special quilt feature in it at this point because it'll be temporary and it'll be more cruft. Speaking of cruft, there are a few false steps that I made when I was implementing DH. There are some flags before and after and things like that. You can pass a DH to control which part of the sequence it runs, and those are all basically cruft at this point because they try not to work very well. So I really need to stress that this is an evolving thing. I've been talking with, for example, Sam Hartman's, and he's pointed out a couple of cases where the emulation of make, the DH does, isn't exactly right, and you might run a target and DH just says, oh, we've already done that, just like as if there's a stamp file for every target, which can be really annoying if you want to run Debian Rules binary twice in a row to see if your change has made the change that you want to make. And so I really think this is still evolving. There'll probably be some minor tweaks or might be a new compatibility level that changes some things. Who knows? I just want to stress that because it's obviously... Thank you. This is obviously still a work in progress. Anybody else? Hello. This is all very good, aren't it? Have you noticed that the dPackage now supports dPackage of Endor, which is a mechanism for building all sorts of derivatives? Haven't noticed that. And having done a lot of rules file patching over the last few years, we've found that by far the easiest way to make things work is if the meta-build systems actually support the changes you want to make rather than changing a million rules files in the same way. And I'm just wondering whether you've looked at or thought about how this stuff might use effectively a dPackage of Endor override like dPackage architecture to say, we're building this flavor and automatically do the right stuff. I have to admit, I haven't even heard about the DH of right Endor or whatever it's called. I think it was mentioned to me earlier this morning, but I haven't really been following the list too much, so you'll have to bring things to my attention directly if you want. I mean, to know about them if there's something that isn't, you know, directly impacting Dev Helper obviously, I guess there is some possible, you know, way to make Dev Helper and DH do the right thing magically if this is set and maybe we can look at doing that. Of course, you still then have to deal with all the rules files that don't use this and that never will, and you know, which is going to continue probably forever. I think we're going to have the old style rules files until the end of time, and I think that's perfectly okay. I don't have any problem with them. Yeah, I mean, dPackage obviously, an awful lot of stuff does use Dev Helper and then if Dev Helper just does the right thing, the maintainers don't need to care, which is exactly what we all want really. Yeah, and if you can get it down to one Dev Helper command or a few Dev Helper commands that need to be modified to do the right thing, that is much easier. If it's a matter of, oh, we want to go and insert, say we're building for Ubuntu, we want to go insert a new Dev Helper command in the sequence automatically type thing, then that gets a little bit more iffy because, you know, DH sequences aren't going to be used for all packages, so that's only solving what was it, 9% of your problem, so... I guess basically anybody who cares about this should come and talk to me and Jerry and people. There'll be an MDB in the box later, which is maybe one place to talk about this. I don't know if there's a better venue, probably not. Is that it? Okay, well, thank you all.