Hi Mo, On Mon, Apr 08, 2019 at 11:18:14AM +0000, Mo Zhou wrote: > The proposed idea is to take some advantages from source-based > software distribution tools. Examples are available here: > https://github.com/dupr/duprkit > https://github.com/dupr/DefaultCollection
I looked into this. Your reasons are sound and you are scratching your itch. This is great. It seems that a key aspect of this thing is avoiding to (re)distribute sources. You give good reasons for why this is needed and I see no need to reiterate or discuss them. 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. 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. 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. * Given that source package's Build-Depends, figure out what other binary packages need to be built. * Recurse. * Build them in a suitable order. (Some people will observe that this is the "bootstrap" problem. ;) 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. Before tackling that problem, the question arises of whether that problem is in scope. Does duprkit really want to handle complex dependencies or is the idea really to just get the stuff into users hands? In the latter case, vendoring likely is a simple way to avoid this problem entirely. 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.) If you go this route, you can just scrape those debian/control files to figure out which .durpkg files to convert into .dsc files. I don't think I would start using such a user repository. I'm much too scared about it. Yet, the second part of the problem seems interesting to me: Taking a (possibly local) repository of source packages and building a specific binary package (plus everything that's needed to get there). I think that you can increase collaboration by changing your interface in a way that makes it easier to reuse in other settings. Helmut
