Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1146390 > unrolled thread

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Ansgar <ansgar@43-1.org> - 2023-05-11 00:00 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Ansgar <ansgar@43-1.org> - 2023-05-11 00:50 +0200
      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Ansgar <ansgar@43-1.org> - 2023-05-18 19:30 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Emilio Pozuelo Monfort <pochu@debian.org> - 2023-05-11 12:40 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Simon Richter <sjr@debian.org> - 2023-05-11 14:30 +0200
      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-11 20:00 +0200
        Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Simon Richter <sjr@debian.org> - 2023-05-12 14:30 +0200
          Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 15:10 +0200
      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Matthew Vernon <matthew@debian.org> - 2023-05-25 14:10 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Ansgar <ansgar@43-1.org> - 2023-05-12 07:50 +0200
      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-12 10:50 +0200
        Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 12:00 +0200
          Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-12 12:50 +0200
            Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 13:00 +0200
            Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-12 13:20 +0200
              Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 14:20 +0200
                Re: Bug#1035904: dpkg currently warning about merged-usr systems  (revisited) Steve McIntyre <steve@einval.com> - 2023-05-12 16:40 +0200
                  Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 17:40 +0200
                Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 01:30 +0200
                  Re: Bug#1035904: dpkg currently warning about merged-usr systems  (revisited) Peter Pentchev <roam@ringlet.net> - 2023-05-15 02:10 +0200
                    Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 02:30 +0200
                  Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-15 02:20 +0200
                    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 02:50 +0200
                      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-15 03:10 +0200
                      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-15 03:40 +0200
                        Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 04:40 +0200
                          Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-15 17:30 +0200
                            Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-16 03:50 +0200
                  Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-15 03:00 +0200
                    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-05-15 07:00 +0200
                      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Bdale Garbee <bdale@gag.com> - 2023-05-15 15:00 +0200
                        Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 15:20 +0200
                          Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Bdale Garbee <bdale@gag.com> - 2023-05-15 18:00 +0200
                            Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Matthew Vernon <matthew@debian.org> - 2023-05-15 18:20 +0200
                              Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Bdale Garbee <bdale@gag.com> - 2023-05-15 18:30 +0200
                                Bug#1035904: What does merged /usr bring us Sam Hartman <hartmans@debian.org> - 2023-05-15 20:40 +0200
                                  Bug#1035904: What does merged /usr bring us Sam Hartman <hartmans@debian.org> - 2023-05-15 20:40 +0200
                                  Bug#1035904: What does merged /usr bring us Jonathan Carter <jcc@debian.org> - 2023-05-15 20:50 +0200
                              Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Sam Hartman <hartmans@debian.org> - 2023-05-15 19:00 +0200
                      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-15 15:40 +0200
                        Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 16:50 +0200
                      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Simon McVittie <smcv@debian.org> - 2023-05-15 20:40 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Simon McVittie <smcv@debian.org> - 2023-05-15 20:00 +0200
      Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-16 04:00 +0200
        Re: Bug#1035904: dpkg currently warning about merged-usr systems  (revisited) Simon McVittie <smcv@debian.org> - 2023-05-16 10:30 +0200
          Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-17 01:50 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Roger Lynn <usenet@rilynn.me.uk> - 2023-05-17 22:50 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Ansgar <ansgar@43-1.org> - 2023-05-18 20:00 +0200
      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Gunnar Wolf <gwolf@debian.org> - 2023-05-18 20:20 +0200
        Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Ansgar <ansgar@43-1.org> - 2023-05-18 20:30 +0200
          Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-18 20:40 +0200
            Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Matthias Klumpp <matthias@tenstral.net> - 2023-05-18 21:20 +0200
            Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Arnaud Rebillout <arnaudr@debian.org> - 2023-05-19 05:20 +0200
        Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Bastian Blank <waldi@debian.org> - 2023-05-18 21:10 +0200
          Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Gunnar Wolf <gwolf@debian.org> - 2023-05-18 21:30 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Ansgar <ansgar@43-1.org> - 2023-05-19 16:40 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Helmut Grohne <helmut@subdivi.de> - 2023-05-21 16:30 +0200
      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Ansgar <ansgar@43-1.org> - 2023-05-21 17:00 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Luca Boccassi <bluca@debian.org> - 2023-05-21 17:00 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Ansgar <ansgar@43-1.org> - 2023-06-07 06:40 +0200
    Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Ansgar <ansgar@43-1.org> - 2023-06-13 21:20 +0200
      Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Matthew Garrett <mjg59@srcf.ucam.org> - 2023-06-13 22:10 +0200
        Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Ansgar <ansgar@43-1.org> - 2023-06-13 22:30 +0200

Page 1 of 4  [1] 2 3 4  Next page →

#1146390 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Package: tech-ctte
X-Debbugs-Cc: Russ Allbery <rra@debian.org>, Sean Whitton <spwhitton@spwhitton.name>, Helmut Grohne <helmut@subdivi.de>, Luca Boccassi <bluca@debian.org>, debian-dpkg@lists.debian.org, debian-devel@lists.debian.org

On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar <ansgar@43-1.org> writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
> 
> Yes, I agree with that part and I think I objected to that at the time.
> Nonetheless, one bad decision doesn't mean that it is Debian policy that
> we don't care about derivatives or their users.  I think we made a mistake
> there which is not in alignment with our ideals or our goals.  We should
> try to reverse that mistake, not double down on it.

Cool, then let's ask tech-ctte.

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Thanks,
Ansgar

  [1]: https://bugs.debian.org/994388#397

[toc] | [next] | [standalone]

#1146394

On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote:
> Cool, then let's ask tech-ctte.
> 
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
> 
> Thanks,
> Ansgar
> 
>   [1]: https://bugs.debian.org/994388#397

For derivatives based on Debian stable it might be worth having this
included in the next stable release; this would need a fairly quick
decision on this issue.

Ansgar

[toc] | [prev] | [next] | [standalone]

#1147152

Hi,

On Thu, 2023-05-11 at 00:32 +0200, Ansgar wrote:
> On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote:
> > Cool, then let's ask tech-ctte.
> > 
> > Dear ctte, please consider overruling the dpkg maintainer to
> > include
> > the patch from #994388[1].
> > 
> > Thanks,
> > Ansgar
> > 
> >   [1]: https://bugs.debian.org/994388#397
> 
> For derivatives based on Debian stable it might be worth having this
> included in the next stable release; this would need a fairly quick
> decision on this issue.

The full freeze is approaching and there has been no progress on this
issue. Does the ctte think a decision before the release is still
possible?

As asked earlier I'm also interested in whether the ctte thinks there
is enough consensus about how this issue should be solved or do we
need a longer discussion to explore the solution space?

I admit not having read all mails in the thread as it went fairly off
topic IMHO.

Ansgar

[toc] | [prev] | [next] | [standalone]

#1146432 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

Hi Sean,

On 11/05/2023 03:59, Sean Whitton wrote:
> Hello,
> 
> On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:
> 
>> Dear ctte, please consider overruling the dpkg maintainer to include
>> the patch from #994388[1].
> 
> Currently dpkg contains code to emit the merged-/usr warning, that's
> dead code on Debian, but which becomes active when packages from the
> Debian archive are copied unmodified into derivatives.
> 
> The heart of the issue is how dpkg is a native package.  What we're
> talking about is not the Debian system, but the Debian archive as it
> exists independently of the Debian system.
> 
> dpkg has an upstream existence that's independent of Debian, and it's
> perfectly legitimate for that version of dpkg to emit the warning.  The
> problem here might be caused by how the Debian archive is implicitly
> being used to distribute upstream dpkg.
> 
> This is not in itself a problem -- we distribute a lot of stuff in
> source packages that does not form part of the Debian system.  But in
> this case, this distribution that's occurring might conflict with how
> Debian is seeking to provide a product not just to end users, but also
> to those building derivatives.
> 
> One simple solution is for dpkg to become a non-native package, carrying
> Debian-specific patches to do things like remove the warning code.

I think you're conflating two independent things.

If you override the dpkg maintainer to remove that warning that occurs on 
derivatives, then anyone could NMU dpkg and the maintainer wouldn't introduce it 
back, effectively removing the warning from "dpkg upstream".

OTOH if the dpkg maintainer switches to non-native packages, anyone could NMU it 
adding the change as a patch, however the maintainer will just NACK the NMU 
before or after it happens.

So I don't see a problem with dpkg being native, just like e.g. apt is, and that 
won't magically solve the issue at hand.

Cheers,
Emilio

[toc] | [prev] | [next] | [standalone]

#1146450 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

Hi,

On 5/11/23 10:59, Sean Whitton wrote:

>> Dear ctte, please consider overruling the dpkg maintainer to include
>> the patch from #994388[1].

> Currently dpkg contains code to emit the merged-/usr warning, that's
> dead code on Debian, but which becomes active when packages from the
> Debian archive are copied unmodified into derivatives.

The way I see it (but I'm not a dpkg maintainer), the current 
implementation is correct, as dpkg does not support aliased directories, 
but Debian has decided to use it in such an environment nonetheless. The 
tech-ctte decision not to roll back usrmerge accepts responsibility for 
this decision, so silencing the warning on Debian is correct, but no one 
has accepted that responsibility for derived distributions.

Any derived distribution can easily go on record and request inclusion 
in the list of distributions where this warning is suppressed, by typing 
the phrase "Yes, I understand that this is a bad idea." into an email 
client.

> dpkg has an upstream existence that's independent of Debian, and it's
> perfectly legitimate for that version of dpkg to emit the warning.  The
> problem here might be caused by how the Debian archive is implicitly
> being used to distribute upstream dpkg.

I'm skeptical about splitting development and packaging, though, 
especially in this context, because we'd need to clarify how far we'd 
want upstream dpkg and Debian dpkg to deviate.

Basically, non-native dpkg has two scenarios: either it is maintained by 
the same people as now, which causes them extra work for no clear 
benefit, or we find maintainers willing to deal with complex bug reports 
that upstream is fully entitled to reject because Debian brought this 
onto themselves by deciding that one upstream project's "unsupported 
configuration" needs to be avoided by moving to another upstream 
project's "unsupported configuration."

Those same people who would volunteer to maintain such a package could 
spend their energy finding a solution that can be merged into "upstream" 
dpkg, that would be more productive.

    Simon

[toc] | [prev] | [next] | [standalone]

#1146488 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Multipart message — attachments visible in raw view] — view raw

On Thu, 11 May 2023 21:16:34 +0900 Simon Richter <sjr@debian.org>
wrote:
> Hi,
> 
> On 5/11/23 10:59, Sean Whitton wrote:
> 
> >> Dear ctte, please consider overruling the dpkg maintainer to
include
> >> the patch from #994388[1].
> 
> > Currently dpkg contains code to emit the merged-/usr warning,
that's
> > dead code on Debian, but which becomes active when packages from
the
> > Debian archive are copied unmodified into derivatives.
> 
> The way I see it (but I'm not a dpkg maintainer), the current 
> implementation is correct, as dpkg does not support aliased
directories, 
> but Debian has decided to use it in such an environment nonetheless.
The 
> tech-ctte decision not to roll back usrmerge accepts responsibility
for 
> this decision, so silencing the warning on Debian is correct, but no
one 
> has accepted that responsibility for derived distributions.
> 
> Any derived distribution can easily go on record and request
inclusion 
> in the list of distributions where this warning is suppressed, by
typing 
> the phrase "Yes, I understand that this is a bad idea." into an email
> client.

The crux of the issue is that we are hearing how negatively affecting
derivatives in any way, even purely theoretically, is a big no-no, in
this very same thread and topic. Reaching out and asking for
directions/help/whatever is not enough in that context. So it follows
that it cannot be enough in this context either, and it must be fixed
instead.

Or alternatively, we can establish that a documentation/post-facto
approach is enough for derivatives, and then that's valid for all
changes and transitions.

Either of these are valid approaches.

What I cannot find acceptable is that some changes get a free pass, and
some get roadblocks after roadblocks thrown at them.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1146578 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

Hi,

On 5/12/23 02:51, Luca Boccassi wrote:

> Or alternatively, we can establish that a documentation/post-facto
> approach is enough for derivatives, and then that's valid for all
> changes and transitions.

For the context of this bug, the notice *is* the after-the-fact 
documentation of an interface change, i.e. the bare minimum.

It would have been better to get input from derived distributions about 
this interface change before it happened, but given that the interface 
change was not caused by a change in dpkg code, but by the introduction 
of the usrmerge package, there was not much of a remedy available then.

    Simon

[toc] | [prev] | [next] | [standalone]

#1146583 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, 12 May 2023 at 13:21, Simon Richter <sjr@debian.org> wrote:
>
> Hi,
>
> On 5/12/23 02:51, Luca Boccassi wrote:
>
> > Or alternatively, we can establish that a documentation/post-facto
> > approach is enough for derivatives, and then that's valid for all
> > changes and transitions.
>
> For the context of this bug, the notice *is* the after-the-fact
> documentation of an interface change, i.e. the bare minimum.
>
> It would have been better to get input from derived distributions about
> this interface change before it happened, but given that the interface
> change was not caused by a change in dpkg code, but by the introduction
> of the usrmerge package, there was not much of a remedy available then.

Not really? This notice is new, and suggests something that will make
the downstream irreparably incompatible with Debian, which I thought
was a big no-no.
If negatively affecting downstreams is a problem, this needs to be
reverted. If it's enough to say somewhere else "actually, that is bad
advice, if you follow it you are on your own", then that's fine too by
me, but then it's fine for other changes as well.

Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1147926 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

Hi,

This thread has rather veered off the initial bug report.

On 11/05/2023 13:16, Simon Richter wrote:
> Hi,
> 
> On 5/11/23 10:59, Sean Whitton wrote:
> 
>>> Dear ctte, please consider overruling the dpkg maintainer to include
>>> the patch from #994388[1].
> 
>> Currently dpkg contains code to emit the merged-/usr warning, that's
>> dead code on Debian, but which becomes active when packages from the
>> Debian archive are copied unmodified into derivatives.
> 
> The way I see it (but I'm not a dpkg maintainer), the current 
> implementation is correct, as dpkg does not support aliased directories, 
> but Debian has decided to use it in such an environment nonetheless. The 
> tech-ctte decision not to roll back usrmerge accepts responsibility for 
> this decision, so silencing the warning on Debian is correct, but no one 
> has accepted that responsibility for derived distributions.
> 
> Any derived distribution can easily go on record and request inclusion 
> in the list of distributions where this warning is suppressed, by typing 
> the phrase "Yes, I understand that this is a bad idea." into an email 
> client.

I have considerable sympathy for this point of view. Further, given 
ongoing (and quite fruitful) discussion on how to resolve the 
outstanding issues around /usr-merge and dpkg, I don't think the 
question of dpkg's warning (and its unfortunate wording) is one that is 
useful for the technical committee (and the dpkg maintainers) to be 
spending time on right now.

I think I would feel differently if there were derivatives who had asked 
the dpkg maintainers to likewise exclude their distro from the warning 
had been rebuffed (though I suspect such folk will just be patching it 
out in their own builds).

Likewise I would expect that once we have finished sorting out the 
outstanding /usr-merge & dpkg issues that the warning would be removed.

But those scenarios aren't where we're at now, so I think the project 
should continue to focus on moving ourselves to the point where dpkg 
does support /usr-merge as implemented in Debian.

Regards,

Matthew

[toc] | [prev] | [next] | [standalone]

#1146529 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote:
> On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:
> > Cool, then let's ask tech-ctte.
> > 
> > Dear ctte, please consider overruling the dpkg maintainer to
> > include
> > the patch from #994388[1].
> > 
> > Thanks,
> > Ansgar
> > 
> >   [1]: https://bugs.debian.org/994388#397
> 
> This would require a new, maintainer-overruling vote.
> Our existing decisions do not apply, so far as I can tell.

Yes, I agree.

> I have written a separate message to the bug and to debian-dpkg with
> a proposal to avoid having to have such a vote.

That seems to be about an implementation detail on how to apply the
patch. I don't think that is the core of the issue?

The core issue as I see it is as follows:

- Debian has decided to support only merged-/usr, including possibly
  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
  as the interpreter in binaries.

- This change breaks on non-merged-/usr systems, including derivatives
  that do not revert *all* relevant changes. (Do you know one that
  does this or plans to do so?)

- dpkg recommends derivative users to move to non-merged-/usr.

I think this contradiction is not good and the core conflict. For me a
distribution should have some coherence. It is not just a distribution
of unrelated parts (like linux, libc, dpkg, dash, ...), but also
integrates them to work together.

And this also means not one package telling users to do X which breaks
other packages. Or (if other packages would do similar things as dpkg)
one package asking users to do X and the other asking users to do the
opposite of X. Just imagine dpkg asking users to move to split-/usr and
then another package starting to warn users to move back to merged-
/usr. Would that be a good state? I think not which is why this bug
exists.

Do you think this summary of the issue is right?

Is there some consensus about how this issue should be solved or do we
need a longer discussion to explore the solution space?

Ansgar

[toc] | [prev] | [next] | [standalone]

#1146546 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>
>The core issue as I see it is as follows:
>
>- Debian has decided to support only merged-/usr, including possibly
>  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
>  as the interpreter in binaries.

WTF? *Nobody* has been talking about breaking ABI like this, that I've
seen. The interpreter must *not* be changed willy-nilly.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth

[toc] | [prev] | [next] | [standalone]

#1146558 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote:
>
> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >
> >The core issue as I see it is as follows:
> >
> >- Debian has decided to support only merged-/usr, including possibly
> >  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
> >  as the interpreter in binaries.
>
> WTF? *Nobody* has been talking about breaking ABI like this, that I've
> seen. The interpreter must *not* be changed willy-nilly.

Nothing's happening 'willy-nilly'. We are discussing a bunch of
seemingly crazy options, as in, "what would _actually_ explode if we
do this or do that?", on this very d-devel thread. I posted a longer
version here some days ago:

https://lists.debian.org/debian-gcc/2023/05/msg00030.html

Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1146565 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote:
>>
>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>> >
>> >The core issue as I see it is as follows:
>> >
>> >- Debian has decided to support only merged-/usr, including possibly
>> >  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
>> >  as the interpreter in binaries.
>>
>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
>> seen. The interpreter must *not* be changed willy-nilly.
>
>Nothing's happening 'willy-nilly'. We are discussing a bunch of
>seemingly crazy options, as in, "what would _actually_ explode if we
>do this or do that?", on this very d-devel thread. I posted a longer
>version here some days ago:
>
>https://lists.debian.org/debian-gcc/2023/05/msg00030.html

Oh holy fuck.

You're talking about changing ABI by doing this. That *is* utterly
crazy. No.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead

[toc] | [prev] | [next] | [standalone]

#1146566 — Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, 12 May 2023 at 11:40, Steve McIntyre <steve@einval.com> wrote:
>
> On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote:
> >>
> >> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >> >
> >> >The core issue as I see it is as follows:
> >> >
> >> >- Debian has decided to support only merged-/usr, including possibly
> >> >  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
> >> >  as the interpreter in binaries.
> >>
> >> WTF? *Nobody* has been talking about breaking ABI like this, that I've
> >> seen. The interpreter must *not* be changed willy-nilly.
> >
> >Nothing's happening 'willy-nilly'. We are discussing a bunch of
> >seemingly crazy options, as in, "what would _actually_ explode if we
> >do this or do that?", on this very d-devel thread. I posted a longer
> >version here some days ago:
> >
> >https://lists.debian.org/debian-gcc/2023/05/msg00030.html
>
> Oh holy fuck.
>
> You're talking about changing ABI by doing this. That *is* utterly
> crazy. No.

It's a thought experiment on a mailing list. If we can't even have
those anymore, something went very wrong somewhere.

You seem to be aware of things that wouldn't work anymore (I think?).
If you have a couple of minutes to spare, may I please ask you to
reply to that thread with such examples? I am genuinely interested in
understanding and talking about it. Thank you.

Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1146570 — Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
>On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote:
>>>
>>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>>> >
>>> >The core issue as I see it is as follows:
>>> >
>>> >- Debian has decided to support only merged-/usr, including possibly
>>> >  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
>>> >  as the interpreter in binaries.
>>>
>>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
>>> seen. The interpreter must *not* be changed willy-nilly.
>>
>>Nothing's happening 'willy-nilly'. We are discussing a bunch of
>>seemingly crazy options, as in, "what would _actually_ explode if we
>>do this or do that?", on this very d-devel thread. I posted a longer
>>version here some days ago:
>>
>>https://lists.debian.org/debian-gcc/2023/05/msg00030.html
>
>Oh holy fuck.
>
>You're talking about changing ABI by doing this. That *is* utterly
>crazy. No.

People have asked me to expand on this further...

I've been involved in defining ABI before, specifically for
armhf. It's not a quick and easy process. It needs buy-in from all
sides to make things work, and people *really* value the
interoperability that it enables.

The interpreter path is one of the most important parts of the ABI
spec, the bit that makes binaries compatible between all the various
stakeholders: compiler/tools people, distros, software vendors,
etc. Lots of the rest of the details downstream of this can be
changed, and people do this all the time - compare multilib to
multi-arch for example. That all works fine *so long as* the runtime
linker can be located and started OK.

Changing the interpreter path would mean moving to a Debian-specific
ABI, breaking that compatibility. Hand-waving that away with (and I
quote):

  "The vast majority of distros today ship the loader in /usr/lib as
  /lib is just a symlink, so it would be interoperable."

is appalling arrogance. No. You do *not* get to break ABI with that
argument. The point of the ABI spec is that *everybody* follows
it. You don't change it just because you think it'll make your life a
little easier when bootstrapping a system.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Welcome my son, welcome to the machine.

[toc] | [prev] | [next] | [standalone]

#1146577 — Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, 12 May 2023 at 12:08, Steve McIntyre <steve@einval.com> wrote:
>
> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote:
> >>>
> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >>> >
> >>> >The core issue as I see it is as follows:
> >>> >
> >>> >- Debian has decided to support only merged-/usr, including possibly
> >>> >  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
> >>> >  as the interpreter in binaries.
> >>>
> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
> >>> seen. The interpreter must *not* be changed willy-nilly.
> >>
> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of
> >>seemingly crazy options, as in, "what would _actually_ explode if we
> >>do this or do that?", on this very d-devel thread. I posted a longer
> >>version here some days ago:
> >>
> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html
> >
> >Oh holy fuck.
> >
> >You're talking about changing ABI by doing this. That *is* utterly
> >crazy. No.
>
> People have asked me to expand on this further...
>
> I've been involved in defining ABI before, specifically for
> armhf. It's not a quick and easy process. It needs buy-in from all
> sides to make things work, and people *really* value the
> interoperability that it enables.
>
> The interpreter path is one of the most important parts of the ABI
> spec, the bit that makes binaries compatible between all the various
> stakeholders: compiler/tools people, distros, software vendors,
> etc. Lots of the rest of the details downstream of this can be
> changed, and people do this all the time - compare multilib to
> multi-arch for example. That all works fine *so long as* the runtime
> linker can be located and started OK.

The loader is still available via the old path, so external/third
party/local/other software works unchanged. This should negatively
only affect our 1st party packages, when running on a non-merged
distro.
And are _all_ our packages really 100% compatible with other distros
at all? Are they even supposed to be?

For example, if I download efibootmgr from Bookworm on an Ubuntu Focal
machine, when I try to run it, it fails:

root@focal:/tmp# wget
http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
--2023-05-12 12:46:17--
http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 27572 (27K) [application/vnd.debian.binary-package]
Saving to: 'efibootmgr_17-2_amd64.deb'

efibootmgr_17-2_amd64.deb
100%[===============================================>]  26.93K
--.-KB/s    in 0.04s

2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572]

root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm
root@focal:/tmp# ./ebm/bin/efibootmgr
./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version
`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr)

Should I file a severity: serious bug against efibootmgr because it is
not interoperable?

The answer is obviously not, because it would be absurd to expect a
binary compiled against libraries from one distro to "just work" on an
entirely different distro. Glibc itself is not forward compatible, and
is allowed to add new symbols, that are not present in older versions,
and packages are allowed to depend on them. Aren't those also ABI
breakages? What about all the libraries that bump soname? What about
binaries that rely on newer kernel interfaces, or IPC interfaces?

So, what I am asking is, what actual, real difference does it make if,
by default (and with an override available for example), packages
built on Debian for Debian record the ld path to point to its (actual)
location on Debian, via say a compiler spec file that is injected in a
deb build?
There very likely is some real difference and impact, and I am
genuinely and honestly asking what it could be. If nothing else, it's
an interesting topic, even if likely nothing comes out of it.

> Changing the interpreter path would mean moving to a Debian-specific
> ABI, breaking that compatibility. Hand-waving that away with (and I
> quote):
>
>   "The vast majority of distros today ship the loader in /usr/lib as
>   /lib is just a symlink, so it would be interoperable."
>
> is appalling arrogance. No. You do *not* get to break ABI with that
> argument. The point of the ABI spec is that *everybody* follows
> it. You don't change it just because you think it'll make your life a
> little easier when bootstrapping a system.

AFAIK there are at least 3 distros where the default interpreter path
is changed to follow distro-specific customizations: Gentoo, Nix,
Guix. So evidently, some people *do* get to "break ABI", and not
everybody follows it. So why can't we at least _talk_ about it, pros
and cons, advantages and problems, without the tones of the discussion
needlessly escalating?

Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1146591 — Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
>On Fri, 12 May 2023 at 12:08, Steve McIntyre <steve@einval.com> wrote:
>>
>> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
>> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote:
>> >>>
>> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>> >>> >
>> >>> >The core issue as I see it is as follows:
>> >>> >
>> >>> >- Debian has decided to support only merged-/usr, including possibly
>> >>> >  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
>> >>> >  as the interpreter in binaries.
>> >>>
>> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
>> >>> seen. The interpreter must *not* be changed willy-nilly.
>> >>
>> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of
>> >>seemingly crazy options, as in, "what would _actually_ explode if we
>> >>do this or do that?", on this very d-devel thread. I posted a longer
>> >>version here some days ago:
>> >>
>> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html
>> >
>> >Oh holy fuck.
>> >
>> >You're talking about changing ABI by doing this. That *is* utterly
>> >crazy. No.
>>
>> People have asked me to expand on this further...
>>
>> I've been involved in defining ABI before, specifically for
>> armhf. It's not a quick and easy process. It needs buy-in from all
>> sides to make things work, and people *really* value the
>> interoperability that it enables.
>>
>> The interpreter path is one of the most important parts of the ABI
>> spec, the bit that makes binaries compatible between all the various
>> stakeholders: compiler/tools people, distros, software vendors,
>> etc. Lots of the rest of the details downstream of this can be
>> changed, and people do this all the time - compare multilib to
>> multi-arch for example. That all works fine *so long as* the runtime
>> linker can be located and started OK.
>
>The loader is still available via the old path, so external/third
>party/local/other software works unchanged. This should negatively
>only affect our 1st party packages, when running on a non-merged
>distro.

So why the hell do you want to break this in the first place? Does a
symlink in the "wrong" place offend you for some reason? For that you
want to change a core assumption in *every single binary* in Debian?
Believe me, I've been here in the past when we made changes in armhf
to accommodate earlier mistakes. That was just for one
architecture. What possible benefit do you see in this change?

>And are _all_ our packages really 100% compatible with other distros
>at all? Are they even supposed to be?
>
>For example, if I download efibootmgr from Bookworm on an Ubuntu Focal
>machine, when I try to run it, it fails:
>
>root@focal:/tmp# wget
>http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
>--2023-05-12 12:46:17--
>http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
>Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
>Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected.
>HTTP request sent, awaiting response... 200 OK
>Length: 27572 (27K) [application/vnd.debian.binary-package]
>Saving to: 'efibootmgr_17-2_amd64.deb'
>
>efibootmgr_17-2_amd64.deb
>100%[===============================================>]  26.93K
>--.-KB/s    in 0.04s
>
>2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572]
>
>root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm
>root@focal:/tmp# ./ebm/bin/efibootmgr
>./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version
>`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr)
>
>Should I file a severity: serious bug against efibootmgr because it is
>not interoperable?

You're wilfully missing the point, and you know it.

>The answer is obviously not, because it would be absurd to expect a
>binary compiled against libraries from one distro to "just work" on an
>entirely different distro. Glibc itself is not forward compatible, and
>is allowed to add new symbols, that are not present in older versions,
>and packages are allowed to depend on them. Aren't those also ABI
>breakages? What about all the libraries that bump soname? What about
>binaries that rely on newer kernel interfaces, or IPC interfaces?
>
>So, what I am asking is, what actual, real difference does it make if,
>by default (and with an override available for example), packages
>built on Debian for Debian record the ld path to point to its (actual)
>location on Debian, via say a compiler spec file that is injected in a
>deb build?
>There very likely is some real difference and impact, and I am
>genuinely and honestly asking what it could be. If nothing else, it's
>an interesting topic, even if likely nothing comes out of it.

I have better things to do than argue about this. I refuse to engage
with this right now. You're talking about breaking things for *no*
discernible benefit that I've seen any discussion about.

>> Changing the interpreter path would mean moving to a Debian-specific
>> ABI, breaking that compatibility. Hand-waving that away with (and I
>> quote):
>>
>>   "The vast majority of distros today ship the loader in /usr/lib as
>>   /lib is just a symlink, so it would be interoperable."
>>
>> is appalling arrogance. No. You do *not* get to break ABI with that
>> argument. The point of the ABI spec is that *everybody* follows
>> it. You don't change it just because you think it'll make your life a
>> little easier when bootstrapping a system.
>
>AFAIK there are at least 3 distros where the default interpreter path
>is changed to follow distro-specific customizations: Gentoo, Nix,
>Guix. So evidently, some people *do* get to "break ABI", and not
>everybody follows it. So why can't we at least _talk_ about it, pros
>and cons, advantages and problems, without the tones of the discussion
>needlessly escalating?

Again: *why* do you want to do this? For all the value here, should we
also discuss switching to PE-COFF from ELF for our binaries? That's
more commonly used...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Is there anybody out there?

[toc] | [prev] | [next] | [standalone]

#1146594 — Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Fri, 12 May 2023 at 15:30, Steve McIntyre <steve@einval.com> wrote:
>
> On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> >On Fri, 12 May 2023 at 12:08, Steve McIntyre <steve@einval.com> wrote:
> >>
> >> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
> >> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote:
> >> >>>
> >> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >> >>> >
> >> >>> >The core issue as I see it is as follows:
> >> >>> >
> >> >>> >- Debian has decided to support only merged-/usr, including possibly
> >> >>> >  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
> >> >>> >  as the interpreter in binaries.
> >> >>>
> >> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
> >> >>> seen. The interpreter must *not* be changed willy-nilly.
> >> >>
> >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of
> >> >>seemingly crazy options, as in, "what would _actually_ explode if we
> >> >>do this or do that?", on this very d-devel thread. I posted a longer
> >> >>version here some days ago:
> >> >>
> >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html
> >> >
> >> >Oh holy fuck.
> >> >
> >> >You're talking about changing ABI by doing this. That *is* utterly
> >> >crazy. No.
> >>
> >> People have asked me to expand on this further...
> >>
> >> I've been involved in defining ABI before, specifically for
> >> armhf. It's not a quick and easy process. It needs buy-in from all
> >> sides to make things work, and people *really* value the
> >> interoperability that it enables.
> >>
> >> The interpreter path is one of the most important parts of the ABI
> >> spec, the bit that makes binaries compatible between all the various
> >> stakeholders: compiler/tools people, distros, software vendors,
> >> etc. Lots of the rest of the details downstream of this can be
> >> changed, and people do this all the time - compare multilib to
> >> multi-arch for example. That all works fine *so long as* the runtime
> >> linker can be located and started OK.
> >
> >The loader is still available via the old path, so external/third
> >party/local/other software works unchanged. This should negatively
> >only affect our 1st party packages, when running on a non-merged
> >distro.
>
> So why the hell do you want to break this in the first place? Does a
> symlink in the "wrong" place offend you for some reason? For that you
> want to change a core assumption in *every single binary* in Debian?
> Believe me, I've been here in the past when we made changes in armhf
> to accommodate earlier mistakes. That was just for one
> architecture. What possible benefit do you see in this change?

As it was mentioned on the list, because it makes bootstrapping
self-contained, that's a real and concrete benefit that some
developers like Helmut care greatly about, and that's why we are
talking about it. To me, it sounds very attractive to have a
self-contained and canonicalized distro-wide configuration. If the
canonical location where certain files are stored in /usr/bin or
/usr/lib, it seems sensible to me to configure Debian software to look
for it where we actually put it, while maintaining compatibility for
external/local software so that it keeps working. And it is also
unclear so far what would outright break - the externally defined ABI
in terms of where the loader can be accessed at, would still be
respected. Hence why questions are being asked. Nobody's being forced
to do anything, this is just a discussion.

> >And are _all_ our packages really 100% compatible with other distros
> >at all? Are they even supposed to be?
> >
> >For example, if I download efibootmgr from Bookworm on an Ubuntu Focal
> >machine, when I try to run it, it fails:
> >
> >root@focal:/tmp# wget
> >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
> >--2023-05-12 12:46:17--
> >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
> >Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
> >Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected.
> >HTTP request sent, awaiting response... 200 OK
> >Length: 27572 (27K) [application/vnd.debian.binary-package]
> >Saving to: 'efibootmgr_17-2_amd64.deb'
> >
> >efibootmgr_17-2_amd64.deb
> >100%[===============================================>]  26.93K
> >--.-KB/s    in 0.04s
> >
> >2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572]
> >
> >root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm
> >root@focal:/tmp# ./ebm/bin/efibootmgr
> >./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version
> >`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr)
> >
> >Should I file a severity: serious bug against efibootmgr because it is
> >not interoperable?
>
> You're wilfully missing the point, and you know it.

I'm trying to determine where the boundary lies. What are the
expectations for interoperability? Are all executables expected to be
self-contained? Can they rely on external config that is guaranteed to
be there on Debian but not elsewhere? Can they rely on external
libraries that are guaranteed to be there on Debian but not elsewhere?
Can they rely on external symlinks that are guaranteed to be there on
Debian but not elsewhere? How is this all defined, and most
importantly, what are the actual use cases being covered?

> >The answer is obviously not, because it would be absurd to expect a
> >binary compiled against libraries from one distro to "just work" on an
> >entirely different distro. Glibc itself is not forward compatible, and
> >is allowed to add new symbols, that are not present in older versions,
> >and packages are allowed to depend on them. Aren't those also ABI
> >breakages? What about all the libraries that bump soname? What about
> >binaries that rely on newer kernel interfaces, or IPC interfaces?
> >
> >So, what I am asking is, what actual, real difference does it make if,
> >by default (and with an override available for example), packages
> >built on Debian for Debian record the ld path to point to its (actual)
> >location on Debian, via say a compiler spec file that is injected in a
> >deb build?
> >There very likely is some real difference and impact, and I am
> >genuinely and honestly asking what it could be. If nothing else, it's
> >an interesting topic, even if likely nothing comes out of it.
>
> I have better things to do than argue about this. I refuse to engage
> with this right now. You're talking about breaking things for *no*
> discernible benefit that I've seen any discussion about.

It is entirely up to you of course, however just saying "things would
break" without mentioning what or how does not help to further our
understanding of the matter at hand. So far reactions are either one
of "what??! weird, but it could actually work!" and "what??! no,
because no!". In the absence of somebody explaining "there's use case
X that we support as per policy/decision/custom/workflow Y that would
break because of Z" I'm finding it very difficult to come to the
conclusion that this would actually be problematic, in practice. I am
here to be enlightened.

> >> Changing the interpreter path would mean moving to a Debian-specific
> >> ABI, breaking that compatibility. Hand-waving that away with (and I
> >> quote):
> >>
> >>   "The vast majority of distros today ship the loader in /usr/lib as
> >>   /lib is just a symlink, so it would be interoperable."
> >>
> >> is appalling arrogance. No. You do *not* get to break ABI with that
> >> argument. The point of the ABI spec is that *everybody* follows
> >> it. You don't change it just because you think it'll make your life a
> >> little easier when bootstrapping a system.
> >
> >AFAIK there are at least 3 distros where the default interpreter path
> >is changed to follow distro-specific customizations: Gentoo, Nix,
> >Guix. So evidently, some people *do* get to "break ABI", and not
> >everybody follows it. So why can't we at least _talk_ about it, pros
> >and cons, advantages and problems, without the tones of the discussion
> >needlessly escalating?
>
> Again: *why* do you want to do this? For all the value here, should we
> also discuss switching to PE-COFF from ELF for our binaries? That's
> more commonly used...

Actually I'd prefer Mach-O - its native graceful support for optional
dependencies (dlopen-like) is really nice! But I digress, and "why" is
explained above and in earlier mails.

Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1146748 — Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

On Sun, 14 May 2023 at 22:37, Josh Triplett <josh@joshtriplett.org> wrote:
>
> On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > The loader is still available via the old path, so external/third
> > party/local/other software works unchanged. This should negatively
> > only affect our 1st party packages, when running on a non-merged
> > distro.
> > And are _all_ our packages really 100% compatible with other distros
> > at all? Are they even supposed to be?
>
> People build things on Debian that are not Debian packages. People
> compile binaries on Debian, and expect them to work on any system that
> has sufficiently new libraries.
>
> This is *not* about Debian packages failing to work on other
> distributions; this is about *software compiled on Debian* faliing to
> work in other environments.

Why would "software compiled on Debian" fail to work in other
environments? Well, there are many reasons actually, people invented
containers/flatpaks/snaps exactly for that reason. But nothing do with
anything discussed here though, as far as I can tell?

> If you build a dynamically linked binary that only depends on glibc, you
> can expect it to be reasonably portable, to any system that uses glibc
> and has a sufficiently new version.
>
> Debian stable is, in fact, one of the common environments people use to
> compile binaries for distribution.

"sufficiently new version" is doing a lot of work there. We have
shlibs dependencies for a reason. In fact, the most common environment
used to distribute binaries is the EOL Ubuntu 16.04, slowly switching
to the soon-to-be-EOL 18.04. glibc is not forward-compatible, new
symbols are added all the time and are used all the time, and you
don't jump on a brand new distribution to do that kind of work, that
would be self-defeating.

> > So, what I am asking is, what actual, real difference does it make if,
> > by default (and with an override available for example), packages
> > built on Debian for Debian record the ld path to point to its (actual)
> > location on Debian, via say a compiler spec file that is injected in a
> > deb build?
>
> Making binaries built *on* Debian different than binaries built *for*
> Debian would introduce a needless additional source of complexity,
> compared to just compiling code the same way in both cases.

That's not how it works today already. There are several significant
differences between just running "gcc sources.c" and building a
package via debhelper on a buildd, they are not the same thing at all,
and they haven't been since forever, there are dozens of
compiler/linker options that the Debian package build environment
sets. Or will you now also ask the distribution to rollback multiarch,
hardening, SOURCE_DATE_EPOCH, -ffile-prefix-map and all the other
reproducibility options, and so on? These and many more are all
"needless additional sources of complexity, compared to just compiling
code the same way" too. Because guess what, there are people who
couldn't possibly care less about
multiarch/security/reproducibility/etc, and there will also be a
subset of users who considers a subset of those compiler options
"needless". So are you going to push to have all of that reverted? And
also are you going to propose a Policy change that forbids adding any
new compiler/linker option to the package build process?

> To frame this in different terms: consider that one of the major goals
> of systemd has been to harmonize across distributions and eliminate
> needless variations that don't serve much actual purpose (e.g.
> variations in config file paths for the same config file). Consider how
> much effort systemd went to work with distributions, understand and deal
> with the *important* variations, and try to convince them to abandon the
> *unimportant* variations. Now imagine if someone came along and said
> "let's patch systemd to put unit files in /purple/; it'll work with
> everything in our distribution".

Pretty sure the Nix folks are already doing pretty much that. And if
it works for their case, all the power to them.

> Or, imagine if someone said "let's inject an argument to gzip, only for
> building the .gz files sihpped in our packages of course, to modify the
> gzip header and remove a few of the extraneous additional fields; it'll
> be fine, because we've patched our gzip to parse it"

Not really related, archives are _intended_ to be opened anywhere for
any reason. Do you have any actual related use case that would no
longer work? Because that would be the easiest and most convincing
counter-factual that could be provided.

> The x86-64 ABI is set. Feel free to make the case to the next
> architecture designer that their new ABI should have the dynamic linker
> in `/usr/lib`. That would *not* have the same downsides, as long as
> everyone agrees on a path.

In practice it is not, though. There are other distributions that
change PT_INTERP for their own purposes, they've already been listed
in this thread. And I am still not hearing any concrete, factual use
case that would be impaired by such a change. I'm beginning to
seriously think there aren't any? Is that really the case?

Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1146752 — Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
> On Sun, 14 May 2023 at 22:37, Josh Triplett <josh@joshtriplett.org> wrote:
> >
> > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > > The loader is still available via the old path, so external/third
> > > party/local/other software works unchanged. This should negatively
> > > only affect our 1st party packages, when running on a non-merged
> > > distro.
> > > And are _all_ our packages really 100% compatible with other distros
> > > at all? Are they even supposed to be?
> >
> > People build things on Debian that are not Debian packages. People
> > compile binaries on Debian, and expect them to work on any system that
> > has sufficiently new libraries.
> >
> > This is *not* about Debian packages failing to work on other
> > distributions; this is about *software compiled on Debian* faliing to
> > work in other environments.
> 
> Why would "software compiled on Debian" fail to work in other
> environments? Well, there are many reasons actually, people invented
> containers/flatpaks/snaps exactly for that reason. But nothing do with
> anything discussed here though, as far as I can tell?

If an ELF executable, compiled on Debian, records its interpreter as
/usr/lib/ld-linux.so.2, what happens when one tries to run it on
a non-usr-merged system? Even one with a recent enough glibc version?

G'luck,
Peter
 
-- 
Peter Pentchev  roam@ringlet.net roam@debian.org pp@storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web