Hi Helmut, Thank you very much for the detailed review! :-)
On Wed, Apr 10, 2019 at 04:56:51PM +0200, Helmut Grohne wrote: > 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. Indeed. > 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. ;) Good point! This is easy to improve. And this suggestion is actually not intrusive at all. AUR's PKGBUILD builder sources the PKGBUILD file for variables and some functions, then execute a pre-defined sequence. Different from that, duprkit's design don't hope to limit the user with any pre-defined "sequence", but enable the users to selectively call the functions they need. In other words, the user can define how to deal with the prepared source+debian directories, afterall the .durpkg header is a shell script. That said, I think some more helper functions would be nice: [1]. > 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. My blueprint includes a very light-weight/simple dependency tracking mechanism. And I assume the project don't need to handle complex dep trees like apt. Because: 1. If a package is common and useful enough, such that it has been adopted by many other projects, why don't I package it for the official Debian release? So, I expect that most packages that DUPR will deal with, are actually leaf or near-leaf packages on the dependency tree. 2. Some of my targeted upstreams do sourceless binary tarball release. They seldom get into the dependency trouble... 3. Inserting a DUPR package into the near-root part of the Debian dependency tree is, generally speaking, a terrible idea. Only those who aware of what they are doing will do this. The simple dep tracking mechanism will be implemented following the Collection-Manifest collection functionality. Everything looks fine so far, and I'll package more stuff to see whether the assumption/blueprint is correct. > 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? No. As explained above. > In the latter case, vendoring likely is a simple way to avoid > this problem entirely. Agreed. > 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.) The `bin/duprCollector` will collect meta information from a collection (and will form a dependency tree in the future). I have no plan to rethink about the "get-orig-source" target since there are ... lots of weird upstreams in my list... > If you go this route, you can just scrape those debian/control files to > figure out which .durpkg files to convert into .dsc files. It will be easy to unfold all .durpkg files into prepared debian/ directories, which makes meta info collection straightforward. To be implemented: [2] > I don't think I would start using such a user repository. I'm much too > scared about it. Understand. The nature of AUR is similar: every user is recommened to review the code before execution to confirm safety. > 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. This is also a good point. At this point I think taking advantages from sbuild would ne a nice direction. tracked at [3] [1] https://github.com/dupr/duprkit/issues/48 [2] https://github.com/dupr/duprkit/issues/49 [3] https://github.com/dupr/duprkit/issues/50
