Hi Micha,
On 2026-04-04 13:11, Micha Lenk wrote:
> Am 3. April 2026 12:23:24 MESZ schrieb Simon Richter <[email protected]>:
>> Build-Depends:
>> qtbase5-dev <bookworm>,
>> libqt5opengl5-desktop-dev <bookworm>,
>> qt6-base-dev <!bookworm>
>>
>> is just *very* convenient for a backport.
>
> As BACKPORTS-NEW queue reviewer I wouldn't like to see such differences
> between the sid upload and the backport upload to be hidden from the debdiff
> output. I fear this will also soon dilute transparency to our users due to
> often poorly (or un-)documented effective changes in debian/changelog that
> are required to facilitate the backport.
this is a really interesting example because it presents conflicting
interests that I was so far oblivious to:
(A) Package maintainers want to use build profiles precisely to avoid
as much delta (= work) as possible in an upload
(B) Archive / queue maintainers want a clear delta to evaluate the
package
It's interesting because both interests obviously have their merits, so
there is no obvious resolution.
> In general I consider build profiles are adding to the complexity of a
> package, making them harder to review. In that sense I would prefer if we do
> not extend their use too easily.
Can you give us some examples of what problems the use of build profiles
could mask / hide during a review?
I don't mean to challenging or anything! I'm just ignorant because
(naturally) I've always only been in the (A) camp.
Any build profile error I can think of should automatically lead to a
FTBFS, and I would assume that anyone using build profiles would have
tested this accordingly, as getting a particular build to work that way
is the entire point.
So I can't immediately think of something that a reviewer would need to
catch -- or could even catch -- that this incantation wouldn't already:
$ sbuild -d trixie-backports -c trixie-amd64 --profiles trixie ...
Best,
Christian
