[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Standardizing source package artifacts build paths

Simon McVittie:

Hi :)

> On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. These would have the following form:
>>   - debian/.build/upstream*
>>     These could be used for out-of-tree builds replacing current
>>     build-tree/ and similar directories.
> Presumably the '*' means it's considered OK for packages that do separate
> production/debug/udeb builds to use multiple directories matching that
> glob?
> For example, a simple debhelper build might eventually (in a future compat
> level) default to "dh $@ --builddirectory=debian/.build/upstream",
> but because src:glib2.0 does separate deb and udeb builds
> (with non-essential features disabled in the udeb), it
> would use "--builddirectory=debian/.build/upstream-deb"
> and "--builddirectory=debian/.build/upstream-udeb" instead
> of its current "--builddirectory=debian/build/deb" and
> "--builddirectory=debian/build/udeb"?

Yes.  :)

Among other, it will hopefully also enable debhelper to support multiple
builds natively or better, when we have a standardized path for these

>>   - We could just (say) .gitignore a single pathname.
>>   - Cleaning the Debian artifacts would imply doing just
>>     «rm -rf debian/.build/» (even though this could be abstracted via a
>>     new dpkg-<something>clean<something> command).
>>   - Namespacing would avoid any collisions.
>>   - Would make parallelization way easier and faster.
>>   - dpkg-dev tools could start defaulting to use package specfific
>>     directories, instead of requiring the user/tool to specify them.
> This all seems good to have.
> The Salsa-CI pipeline (which runs in a git clone of a package, and
> currently uses debian/output/ for intermediate build stuff) could maybe
> also move its scratch directory to debian/.build/salsa-ci.
> Have you seen <https://bugs.launchpad.net/launchpad/+bug/1845159> and
> related discussions in the context of sbuild and pbuilder? It seems
> like a related topic. [...]
> For example, dpkg-buildpackage could perhaps read one glob per
> line from debian/artifacts and hardlink matched files (if any) into
> debian/.build/artifacts for collection by a "larger" framework like
> sbuild or pbuilder, or individual packages could copy/link files into there
> as they go, or debhelper build-system classes like Autotools and Meson
> could know the names of common log files from their build system, or
> some combination of those.
>     smcv

I could see how having a well-defined method for extracting artifacts
will be useful (also for CI purposes).

Though, can you elaborate a bit on why the above approach would be
better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
easy way to declare additional artifacts to be extracted?
  I am fine either way, but I could image that the
debian/.build/artifacts will feature interact with e.g.
"dpkg-buildpackage -tc" where a AUTOPKGTEST_ARTIFACTS replacement would not.


Reply to: