Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Helmut Grohne <helmut@subdivi.de>]

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