[buildd-tools-devel] Bug#844457: Bug#844457: sbuild: --extra-package is great, but could be better

[Johannes Schauer]

Hi,

Quoting Barry Warsaw (2016-11-16 00:04:20)
> I use --extra-package to build new versions of packages that grow new
> dependencies not yet in Debian.  While waiting for the latter to clear NEW
> (or before the ITP-fixing upload), I can use --extra-package on the
> dependency to ensure that it builds correctly.
> 
> That's great, but --extra-package is rather inconvenient because if I
> have to depend on multiple .debs, I need to type out a bunch of
> - --extra-package options.  E.g. to add both python-foo and python3-foo.
> 
> I have two suggestions to make this a little nicer.
> 
> 1) Allow for passing wildcards to --extra-package.  Then I could do
> something like `sbuild ... --extra-package=/path/to/itp/*.deb` and
> have it pick up all the debs in that directory.
> 
> 2) Provide a shortcut option for --extra-package.

it seems that what you want is not to pass individual .deb files but a
repository of them. Why not just put all your .deb into a directory, call
"apt-ftparchive release" to create a Release file, start a http server inside
that directory with "python3 -m http.server 8000 --bind 127.0.0.1" and then
use:

sbuild --extra-repository="deb [trusted=yes] http://127.0.0.1:8000 ./"

This sounds like much but since you explained that you are doing this very
often you could:

 - put the --extra-repository into your ~/.sbuildrc using $extra_repositories
 - configure a webserver to always serve from your chose directory locally (if
   you don't like the idea to have yet another service running in the
   background, you could even use an inetd based http server)
 - regenerate your archive using a simple inotify watcher on your chosen
   directory

Then, whenever you have a new .deb, you'd just throw it into that directory and
when you call "sbuild" (without arguments) it would pick up everything you
need.

Would that not be superior to complicating the sbuild command line?

Apt repositories is an existing mechanism for bundling up multiple binary
packages and I'd not like to re-implement that existing way of doing the
bundling.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20161116/553f817f/attachment.sig>