On 10.04.19 16:56, Helmut Grohne wrote: Hi,
> I looked into this. Your reasons are sound and you are scratching your> itch. > This is great. ACK. It's always good when people make their hands dirty and work on solving actual problems. Even if the actual output (=code, etc) finally doesn't get wide use or even thrown away completely, we still a lot that way. When I look back into my earlier years, I've written lots of things that never have been actually used, but I've learned a lot that way. > Your implementation goes straight from .durpkg -> .deb. I question this> > decision: We already have lots of tools to go from .dsc to .deb. Your> implementation replicates part of that and I think, this is bad as it> makes it harder to collaborate. I did a similar decision w/ dck-buildpackage, because I came to the conclusion that intermediate steps via dsc are just unncessary complexity and slowdown. But the motivation of dck-buildpackage was getting rid of complicated and cumbersome things like pbuilder. So, I can understand to his decision - he probably doesn't need anything from the dsc-based tools, as he's operating in a completely different scope. > Let me propose a rather intrusive interface change to duprkit. What if> the > result of building a .durpkg was a .dsc rather than a .deb? Then you> could split duprkit into two tools:> > * One tool to build source packages from .durpkg files on demand.> * One tool to build a specific binary package from a given deb-src> repository. Let me propose an even more consequent approach: let it operate even one step earlier in the pipeline by just generating a debianized source tree. You could then use the tool of your choice to create dsc from that and put in whatever kind of pipeline you prefer. My personal choice here would be dck-buildpackage, and my infrastructure ontop of that. By the way, this opens up another common topic: how do we get from an upstream tree (in git repo) to a debianzed source tree w/ minimal manual efforts ? > Now in principle, the latter is simply sbuild or pbuilder, but there is> more > to it:> * Given the binary package name, figure out which source package must> be built. Yet another tricky issue. The primary data source for that usually are the control files. But they also somethimes are autogenerated. Could we invent some metadata language for this, that also can handle tricky cases like the kernel ? > * Given that source package's Build-Depends, figure out what other> > binary packages need to be built.> * Recurse.> * Build them in a suitable order. You're talking about building whole overlay repos ? Then I might have something for you: https://github.com/metux/deb-pkg Note: it's still pretty hackish and needs some local per-project customizations. Haven't had the time to make some general purpose standalone package of it. I'm just using it for building per private extra repos for my customers. If anybody likes to join in and turn it into some general purpose package, let's talk about that in a different thread. The first step would be creating a decent command line interface (for now, the run-* scripts are just project-specific dirty hacks to save me from typing too much ;-)). > (Some people will observe that this is the "bootstrap" problem. ;) Not really bootstrap problem, but depenency problem. Easier to solve :p > There is one major difficulty here (and duprkit doesn't presently solve> that > either): If you figure that some binary package is missing, you> have no way of knowing which .durpkg file to build to get the relevant> source package. Yes, he'd have to reinvent the dependency handling. This is one of the points that let me question the whole approach and favour completely different approaches like classic containers. > Now let's assume that you do want to allow complex dependencies in this > user repository. In this case, it would make sense to trade .durpkg > files for plain "debian" directories with an additional debian/rules > target to obtain the source. (We removed "get-orig-source" from policy a > while ago, but maybe this is what you want here.) Sounds a good idea. Maybe we should put this to a broader discussion, along w/ the control file generation problem. My desired outcome of that would be a generic way for fully automatically building everything from a debianzed source tree (eg. git repo) within a minimal container/jail, w/o any other extra configuration outside that source tree - even for those cases where the control file needs to be generated, which again needs some deps. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287