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

Re: Produce extra build artifacts during package builds

Simon McVittie:

On Fri, 02 Aug 2024 at 18:17:52 +0200, Niels Thykier wrote:

Simon McVittie:

In the design that I prototyped, it's declarative, loosely inspired by
the equivalent Gitlab-CI feature:

- the maintainer can write patterns into debian/build-artifacts for
    package-specific quirks like GTK's reftests
    (#-prefixed comments are allowed)


I am a bit tempted to keep this one out of the spec and leave it to the
build-helper to define it. I find that files in `debian/` are not very
discoverable and they are harder to support properly in tooling like
`debputy lsp server`. Each file format requires extra setup and there is not
a good way to announce they exist unlike fields in `debian/control`.  For
`debputy` based packages, I would prefer to have this in the
`debian/debputy.manifest`, since that will enable me to guide the packager
to its existence and provide on-line documentation for it.


That's fine, debputy could read a list of patterns out of its own input
file and "register" them via whatever mechanism exists
(debian/extra-build-artifacts in my prototype, or writing them into an
"artifacts patterns" directory in your suggestion).

I wanted there to be a straightforward way for a maintainer to opt-in
to this, even if they are not yet living in the debputy future, because
I'd prefer to be able to adopt useful features one at a time, rather
than having to rewrite key packages' build systems in debputy syntax
as a blocker for finding out why their tests fail.  [...]
My argument was that `debhelper` and `debputy` would each define how they provide this functionality to their consumers in a way that fits how their style. Not that `debputy` was going to be mandatory for this feature. 



Or, is it possible to have a debputy manifest exist, and get the
information in it about artifacts copied out appropriately, without
needing to make debputy drive the entire build?
The `debputy` framework already has two "integration modes" where `dh` drives the build. As an example, the `dh-sequence-zz-debputy-rrr` build-dependency is useful for getting rid of implicit `fakeroot` / `Rules-Requires-Root: binary-targets` for static ownership while keeping *most* things as you know them.
While adding a third mode would be possible at this junction, I would not go down this route for the `debhelper` support as it would imply an extra dependency for `debhelper` (a circular one at that) plus it would not fit the usual `debhelper` pattern. 


Mattia's wiki page does list "A reproducible
compiler error (ICE) produces a /tmp/cc*.out containing the preprocessed
source.", which might need some tweaking compared to the "the
-artifacts.tar.gz is always a subset of the build tree".


Hmm, yes, that's unfortunate. This wouldn't be compatible with the
Gitlab-CI feature that I was inspired by, either.

     smcv
Indeed. But as said, I am pretty sure we can figure out a solution to this problem. I think it is more of a question whether it will be supported initially (might require a per-source TMPDIR too for buildd support, so artifacts does not get tainted because the buildd was running two builds at the same time, where once had ICE errors and the other had not). It will be fun to solve, I am sure. :D 

Best regards,
Niels
PS: If anyone is maintaining a `Rules-Requires-Root: binary-targets` package and want to migrate away from the implicit `fakeroot` build-dependency, please let me know. I am happy to look at providing patches (`debputy` is only required for static ownership though. Often it is just a matter of masking `chown/chgrp` or `-o` + `-g` for `install`).
Reply to: