Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
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
Reply to: