tho...@goirand.fr:
[...]
Hi Niels,
Thanks a lot for your work on this, I very much agreed with the premiss that
subst vars were a thing easy to fall into traps. It is a very welcomed
improvement to automate them and avoid mistakes.
Is there a place where you wrote some kind of doc about
Sent from Workspace ONE Boxer
On Mar 25, 2024 7:44 AM, Niels Thykier wrote:
>
> Niels Thykier:
> A follow up on this:
>
> * The proposal is now implemented in debhelper compat 14 (as of version
> 13.15+) and debputy (0.1.21+).
>
> * The `debputy` migration tool will flag
Niels Thykier:
Hi
It seems the discussion on this topic has settled, so I am now doing a
summary of the discussion as I understand it.
* Generally, the original proposal seems to have been received
favorably at a conceptual level.
[...]
A follow up on this:
* The proposal is now
> Can we also consider ${*:Built-Using} as typically seen in
> ${sphinxdoc:Built-Using}?
> This is another field that people keep forget adding. While missing
> this field is not severely harmful, having it automatically handled
> would be beneficial.
Automatic expansion of
Hi
It seems the discussion on this topic has settled, so I am now doing a
summary of the discussion as I understand it.
* Generally, the original proposal seems to have been received
favorably at a conceptual level.
* Several people requested the scope to be expanded to extra fields.
None of this is relevant to the substvars discussion, but the collectd
side is worth looking at on its own.
On Sat, Feb 24, 2024 at 01:36:33PM +0100, Gioele Barabucci wrote:
> On 24/02/24 11:26, Bernd Zeimetz wrote:
> > Absolutely. collectd for example - otherwise you would install *all*
> >
Hi!
On Fri, 2024-02-23 at 17:59:14 -0800, Steve Langasek wrote:
> One generic case that this doesn't handle is Essential: yes packages. For
> many of these, the ${shlibs:Depends} gets promoted in debian/control to
> Pre-Depends, not to Depends.
Ah! Good point.
I think the particular case of
Am 24. Februar 2024 11:26:56 MEZ schrieb Bernd Zeimetz :
>On Thu, 2024-02-22 at 20:52 +0100, IOhannes m zmölnig wrote:
>>
>> While I like the idea in general, I wonder how I could override these
>> automatic additions.
>> I think there are some packages that even demote `${shlibs:Depends}`
>> to
On Feb 22, IOhannes m zmölnig wrote:
> While I like the idea in general, I wonder how I could override these
> automatic additions.
> I think there are some packages that even demote `${shlibs:Depends}` to
> Recommends.
E.g. inn2 does:
override_dh_shlibdeps:
dh_shlibdeps
Le Thu, Feb 22, 2024 at 08:52:36PM +0100, IOhannes m zmölnig a écrit :
> Am 22. Februar 2024 20:25:32 MEZ schrieb Boyuan Yang :
> >在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
> >> I think our package helper tooling should just automatically aggregate
> >> all provided substvars of the format
Gioele Barabucci:
On 24/02/24 11:26, Bernd Zeimetz wrote:
On Thu, 2024-02-22 at 20:52 +0100, IOhannes m zmölnig wrote:
I think there are some packages that even demote `${shlibs:Depends}`
to Recommends.
Absolutely. collectd for example - otherwise you would install *all*
plugin dependencies
On 24/02/24 11:26, Bernd Zeimetz wrote:
On Thu, 2024-02-22 at 20:52 +0100, IOhannes m zmölnig wrote:
I think there are some packages that even demote `${shlibs:Depends}`
to Recommends.
Absolutely. collectd for example - otherwise you would install *all*
plugin dependencies with collectd,
On Thu, 2024-02-22 at 20:52 +0100, IOhannes m zmölnig wrote:
>
> While I like the idea in general, I wonder how I could override these
> automatic additions.
> I think there are some packages that even demote `${shlibs:Depends}`
> to Recommends.
>
Absolutely. collectd for example - otherwise
Steve Langasek:
Hi Niels,
On Thu, Feb 22, 2024 at 07:32:21PM +0100, Niels Thykier wrote:
[...]
I am omitting Breaks, Conflicts, and Replaces because I am not aware of any
users of these at the moment. I am open to adding them, if there is a strong
use-case.
One generic case that this
Hi Niels,
On Thu, Feb 22, 2024 at 07:32:21PM +0100, Niels Thykier wrote:
> When I am talking about package relationship substvars, I mean basically any
> substvar of the format ${*:} where Field is a relationship field such
> as Depends, Pre-Depends, etc.
[...]
> I think our package helper
On Thu, Feb 22, 2024 at 09:40:22PM +0100, Matthias Klose wrote:
> Package: libgcc-13-dev
> Recommends: ${dep:libcdev}
> Depends: gcc-13-base (= ${gcc:Version}), ${dep:libgcc}, ${dep:libssp},
> ${dep:libgomp}, ${dep:libitm},
> ${dep:libatomic}, ${dep:libbtrace}, ${dep:libasan}, ${dep:liblsan},
>
On 2024-02-23, Niels Thykier wrote:
> If it was to happen, I suspect that ${shlibs:Depends} would not be the
> best argument. First off, dpkg-shlibdeps has infrastructure to
> selectively demote scanned elf binaries to a different substvar.
> Secondly, I struggle to think of a real world case,
Guillem Jover:
Hi!
On Thu, 2024-02-22 at 19:32:21 +0100, Niels Thykier wrote:
[...]
Right, this is annoying. This was actually brought up some time
ago (2010) in debian-devel as part of #597340. There was not much
reaction at the time (one good, a couple bad).
I reinvented a decade old
IOhannes m zmölnig:
[...]
While I like the idea in general, I wonder how I could override these automatic
additions.
I think there are some packages that even demote `${shlibs:Depends}` to
Recommends.
mfh.her.fsr
IOhannes
I had the same conceptual concern when I originally thought about
Simon McVittie:
On Thu, 22 Feb 2024 at 20:43:21 +0100, Niels Thykier wrote:
Simon McVittie:
On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote:
We could also make unused substvars a hard failure (FTBFS).
I'd prefer not this
Reminder: My proposal only covers ${foo:Depends} and
Hi!
On Thu, 2024-02-22 at 23:14:13 +0100, gregor herrmann wrote:
> On Thu, 22 Feb 2024 19:32:21 +0100, Niels Thykier wrote:
> > If you forget to add a susbtvars that you should added, it is a latent RC
> > bug with only a warning from dpkg-gencontrol that you might miss if you grab
> > a coffee
Hi!
On Thu, 2024-02-22 at 19:32:21 +0100, Niels Thykier wrote:
> Our current way of dealing with package relationship substvars such as
> ${misc:Depends} has been annoying me for a while. As it is, we are stuck in
> this way setup where the "Depends" field in debian/control is de facto
>
On 2024-02-22 12:32, Niels Thykier wrote:
I am omitting Breaks, Conflicts, and Replaces because I am not aware of
any users of these at the moment. I am open to adding them, if there is
a strong use-case.
I think you should include them (and Enhances as Sam Hartman mentioned)
for
On Thu, 22 Feb 2024 19:32:21 +0100, Niels Thykier wrote:
> I think our package helper tooling should just automatically aggregate all
> provided substvars of the format ${*:Depends} and append it the Depends
> field. Rinse and repeat for other relationship fields.
I very much like this proposal.
> "Niels" == Niels Thykier writes:
Niels> # The proposal
Niels> I think our package helper tooling should just automatically
Niels> aggregate all provided substvars of the format ${*:Depends}
Niels> and append it the Depends field. Rinse and repeat for other
Niels>
On 22.02.24 20:43, Niels Thykier wrote:
Simon McVittie:
We could also make unused substvars a hard failure (FTBFS).
I'd prefer not this, because this would be really painful if you're
using substvars for something other than a simple list of dependencies,
like gobject-introspection does:
On Thu, Feb 22, 2024 at 08:52:36PM +0100, IOhannes m zmölnig wrote:
> Am 22. Februar 2024 20:25:32 MEZ schrieb Boyuan Yang :
> >在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
> >> I am omitting Breaks, Conflicts, and Replaces because I am not aware of
> >> any users of these at the moment. I am
Am 22. Februar 2024 20:25:32 MEZ schrieb Boyuan Yang :
>在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
>> I think our package helper tooling should just automatically aggregate
>> all provided substvars of the format ${*:Depends} and append it the
>> Depends field. Rinse and repeat for other
On Thu, 22 Feb 2024 at 20:43:21 +0100, Niels Thykier wrote:
> Simon McVittie:
> > On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote:
> > > We could also make unused substvars a hard failure (FTBFS).
> >
> > I'd prefer not this
>
> Reminder: My proposal only covers ${foo:Depends} and
Quoting Boyuan Yang (2024-02-22 20:25:32)
> 在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
> > I think our package helper tooling should just automatically aggregate
> > all provided substvars of the format ${*:Depends} and append it the
> > Depends field. Rinse and repeat for other relationship
Boyuan Yang:
[...]
Can we also consider ${*:Built-Using} as typically seen in
${sphinxdoc:Built-Using}?
This is another field that people keep forget adding. While missing
this field is not severely harmful, having it automatically handled
would be beneficial.
Thanks,
Boyuan Yang
Simon McVittie:
On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote:
I think our package helper tooling should just automatically aggregate all
provided substvars of the format ${*:Depends} and append it the Depends
field. Rinse and repeat for other relationship fields.
I recently
在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
> I think our package helper tooling should just automatically aggregate
> all provided substvars of the format ${*:Depends} and append it the
> Depends field. Rinse and repeat for other relationship fields.
>
> The list of fields where this is
On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote:
> I think our package helper tooling should just automatically aggregate all
> provided substvars of the format ${*:Depends} and append it the Depends
> field. Rinse and repeat for other relationship fields.
I recently added
Our current way of dealing with package relationship substvars such as
${misc:Depends} has been annoying me for a while. As it is, we are stuck
in this way setup where the "Depends" field in debian/control is de
facto mandatory. It is an RC bug (waiting to happen) if you omit
${misc:Depends}
35 matches
Mail list logo
