Re: Question Under Proposal D: Compile Time Option

[Thomas Goirand]

Hi Sam,

On 12/2/19 6:12 PM, Sam Hartman wrote:
>> "Thomas" == Thomas Goirand  writes:
> 
> Thomas> Sam,
> 
> Thomas> Is this a real life case (if so, please name the
> Thomas> package...), or just a pure fictional one, just because you
> Thomas> love debating?
> 
> Thomas> Cheers,
> 
> So, first of all, note that this question has already been adequately
> answered:
> * the significant effect on systemd installations criteria is the
> biggest consideration
> *  compiling twice  or turning into runtime configuration are the
> biggest mittigation.
> 
> I had at least two situations in mind: Gnome (say policykit) and
> libvert.
> They are a bit different.
> 
> I think your tone is overly confrontational.

This is a very short sentence, and nothing aggressive in it. Please
re-read with this in mind.

Moving forward, I'll try to re-read what I send, add a smile or
something, so that it becomes more obvious that I don't have bad intention.

> based on several previous messages, it was clear at the time I wrote the
> message that it was a real issue.
> Ian knew that; Simon knew that.

It wasn't for me, and it I'm happy to know more now.

> You come along a couple of days later and imply that I might not have
> been acting in good faith and make Debian just a little less nice to be
> in.

Sam, I haven't done that at all. If that's the perception, sorry for the
bad choice of words.

Cheers,

Thomas Goirand (zigo)

Re: Question Under Proposal D: Compile Time Option

[Florian Weimer]

* Neil McGovern:

> On Mon, Dec 02, 2019 at 05:18:35PM +0100, Thomas Goirand wrote:
>> On 11/29/19 11:32 PM, Sam Hartman wrote:
>> > Imagine that we have a program that has compile time support for systemd
>> > and for other mechanisms.  It provides enhanced functionality when built
>> > against systemd, but when so built, it cannot run without systemd.
>> > 
>> Is this a real life case (if so, please name the package...), or just a
>> pure fictional one, just because you love debating?
>> 
>
> Or a hypothetical one, but one which could be fairly reasonable to
> expect. This GR seems to be trying to put in place a statement on what
> exactly we mean by support, and so considering things which may
> reasonably happen in the future is something that we should do.

It's certainly what we have seen with SELinux, where support causes
packages to grow additional library dependencies.  Even though
libselinux is overall quite benign (even Fedora and downstreams do not
*require* that the kernel activates SELinux), I'm sure it initially
caused problems for chroot setups.

Re: Question Under Proposal D: Compile Time Option

[Ansgar]

Thomas Goirand writes:
> On 11/29/19 11:32 PM, Sam Hartman wrote:
>> Ian, I find  that I'm not able to answer Simon's question with regard to
>> Proposal D.
>>
>> Imagine that we have a program that has compile time support for systemd
>> and for other mechanisms.  It provides enhanced functionality when built
>> against systemd, but when so built, it cannot run without systemd.
>>
>> It's packaged that way in Debian.
>> Someone files a bug with a patch that changes the compilation option to
>> support the non-systemd bug, removing the enhanced systemd
>> functionality.
>>
>> What does proposal D say about this?
>> Is the package RC buggy under proposal D until this patch is applied?
>> Does the maintainer have the option to retain the enhanced
>> functionality?
>
> Sam,
>
> Is this a real life case (if so, please name the package...), or just a
> pure fictional one, just because you love debating?

Some people have suggested to do this for policykit-1 to support other
implementations than systemd-logind for some functions.

The policykit-1 maintainers did not want to do this as it complicates
packaging and, more importantly, package relationships (it's very hard
to get the right packages installed in some cases in Debian's dependency
system; see [1] for a related example).

Ansgar

  [1] 
https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-shim_installed=on_legend=on=1

Re: Question Under Proposal D: Compile Time Option

[Sam Hartman]

> "Thomas" == Thomas Goirand  writes:

Thomas> Sam,

Thomas> Is this a real life case (if so, please name the
Thomas> package...), or just a pure fictional one, just because you
Thomas> love debating?

Thomas> Cheers,

So, first of all, note that this question has already been adequately
answered:
* the significant effect on systemd installations criteria is the
biggest consideration
*  compiling twice  or turning into runtime configuration are the
biggest mittigation.

I had at least two situations in mind: Gnome (say policykit) and
libvert.
They are a bit different.

I think your tone is overly confrontational.
based on several previous messages, it was clear at the time I wrote the
message that it was a real issue.
Ian knew that; Simon knew that.
Someone else came along and gave a great response (talking about
compiling twice).
Ian pointed out that I'd missed the significant effect on non-systemd
systems criteria, which was helpful to me.  I regret missing that
detail, but these issues are complex enough we all make mistakes from
time to time.

Basically several of us all assumed good faith of each other and had a
great discussion.
You come along a couple of days later and imply that I might not have
been acting in good faith and make Debian just a little less nice to be
in.
Please don't.

Re: Question Under Proposal D: Compile Time Option

[Neil McGovern]

On Mon, Dec 02, 2019 at 05:18:35PM +0100, Thomas Goirand wrote:
> On 11/29/19 11:32 PM, Sam Hartman wrote:
> > Imagine that we have a program that has compile time support for systemd
> > and for other mechanisms.  It provides enhanced functionality when built
> > against systemd, but when so built, it cannot run without systemd.
> > 
> Is this a real life case (if so, please name the package...), or just a
> pure fictional one, just because you love debating?
> 

Or a hypothetical one, but one which could be fairly reasonable to
expect. This GR seems to be trying to put in place a statement on what
exactly we mean by support, and so considering things which may
reasonably happen in the future is something that we should do.

I don't find your phrasing as a binary choice useful, and ascribing
motives to Sam seems disingenuous.

Neil
-- 


signature.asc
Description: PGP signature

Re: Question Under Proposal D: Compile Time Option

[Thomas Goirand]

On 11/29/19 11:32 PM, Sam Hartman wrote:
> 
> Ian, I find  that I'm not able to answer Simon's question with regard to
> Proposal D.
> 
> Imagine that we have a program that has compile time support for systemd
> and for other mechanisms.  It provides enhanced functionality when built
> against systemd, but when so built, it cannot run without systemd.
> 
> It's packaged that way in Debian.
> Someone files a bug with a patch that changes the compilation option to
> support the non-systemd bug, removing the enhanced systemd
> functionality.
> 
> What does proposal D say about this?
> Is the package RC buggy under proposal D until this patch is applied?
> Does the maintainer have the option to retain the enhanced
> functionality?

Sam,

Is this a real life case (if so, please name the package...), or just a
pure fictional one, just because you love debating?

Cheers,

Thomas Goirand (zigo)

Re: Question Under Proposal D: Compile Time Option

[Ian Jackson]

Thibaut Paumard writes ("Re: Question Under Proposal D: Compile Time Option"):
> I think the right fix would be to compile the package twice as "foo"
> (for the systemd version) and "foo-non-systemd".
> 
> Another option would be to ship both versions in package "foo" and
> decide at runtime which one to run, if technically feasible.

I agree.

> My understanding of D.7 is that, If someone provides a patch that
> implements either of this in a maintainable fashion, this patch should
> be accepted.

Yes.

Simon asked whether under my option a patch to just switch to the
non-systemd version would have to be accepted.  In proposal this
depends on whether the effect on systemd installations is
"substantial".

But what is really being decided there is who is given the task of
changing the packaging to have it build both versions.  Given that the
maintainer is going to have to deal with whatever approach is taken to
building twice that doesn't seem like it makes much difference in
practice: the maintainer is probably going to want to do that work
themselves anyway, so that it is done the way they like it.

I do think this is a suboptimal situation and it would be much better
to patch the code to be able to make the choice at runtime.  I'm
hoping this kind of thing won't be very common.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Question Under Proposal D: Compile Time Option

[Russ Allbery]

Bernd Zeimetz  writes:
> On 11/30/19 8:58 AM, Thibaut Paumard wrote:

>> I think the right fix would be to compile the package twice as "foo"
>> (for the systemd version) and "foo-non-systemd".

>> Another option would be to ship both versions in package "foo" and
>> decide at runtime which one to run, if technically feasible.

>> My understanding of D.7 is that, If someone provides a patch that
>> implements either of this in a maintainable fashion, this patch should
>> be accepted.

> I'm wondering what the security team says to this approach. Who is
> actually going to review these changes, given the fact that most of the
> features in systemd that need patches in packages are somehow security
> relevant.

In the Kerberos world, we've shipped two binary packages build from the
same source package against MIT Kerberos and Heimdal for some time in
places where that makes sense.  It hasn't been much of a problem in
practice, although obviously it's extra packaging work.

-- 
Russ Allbery (r...@debian.org)  

Re: Question Under Proposal D: Compile Time Option

[Bernd Zeimetz]

On 11/30/19 8:58 AM, Thibaut Paumard wrote:
> I think the right fix would be to compile the package twice as "foo"
> (for the systemd version) and "foo-non-systemd".
> 
> Another option would be to ship both versions in package "foo" and
> decide at runtime which one to run, if technically feasible.
> 
> My understanding of D.7 is that, If someone provides a patch that
> implements either of this in a maintainable fashion, this patch should
> be accepted.


I'm wondering what the security team says to this approach. Who is
actually going to review these changes, given the fact that most of the
features in systemd that need patches in packages are somehow security
relevant.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Question Under Proposal D: Compile Time Option

[Thibaut Paumard]

Le 29/11/2019 à 23:32, Sam Hartman a écrit :
> 
> Ian, I find  that I'm not able to answer Simon's question with regard to
> Proposal D.
> 
> Imagine that we have a program that has compile time support for systemd
> and for other mechanisms.  It provides enhanced functionality when built
> against systemd, but when so built, it cannot run without systemd.
> 
> It's packaged that way in Debian.
> Someone files a bug with a patch that changes the compilation option to
> support the non-systemd bug, removing the enhanced systemd
> functionality.
> 
> What does proposal D say about this?
> Is the package RC buggy under proposal D until this patch is applied?
> Does the maintainer have the option to retain the enhanced
> functionality?
> 


Dear Sam,


I think the right fix would be to compile the package twice as "foo"
(for the systemd version) and "foo-non-systemd".

Another option would be to ship both versions in package "foo" and
decide at runtime which one to run, if technically feasible.

My understanding of D.7 is that, If someone provides a patch that
implements either of this in a maintainable fashion, this patch should
be accepted.

Kind regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Question Under Proposal D: Compile Time Option

[Sam Hartman]

Ian, I find  that I'm not able to answer Simon's question with regard to
Proposal D.

Imagine that we have a program that has compile time support for systemd
and for other mechanisms.  It provides enhanced functionality when built
against systemd, but when so built, it cannot run without systemd.

It's packaged that way in Debian.
Someone files a bug with a patch that changes the compilation option to
support the non-systemd bug, removing the enhanced systemd
functionality.

What does proposal D say about this?
Is the package RC buggy under proposal D until this patch is applied?
Does the maintainer have the option to retain the enhanced
functionality?