Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
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
info@metux.net -- +49-151-27565287
Reply to: