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

Re: DEP 17: Improve support for directory aliasing in dpkg



Will get to the rest later tonight, two quick points:

On Mon, 8 May 2023 at 09:58, Helmut Grohne <helmut@subdivi.de> wrote:
> > But the more I think about it, the more I am convinced that the
> > default option working best for Debian is the one that matches the
> > project's choice of a filesystem layout. After all, this is
> > configurable in the toolchain for a reason.
> > And the vast majority of the rest of the world has long since finished
> > this transition, so I struggle to think where software built with this
> > default wouldn't work. Bullseye will be oldoldstable at that point,
> > and even that was default merged for new installations, and really old
> > ones (oldoldoldoldstable at that point? I lost count) will be long
> > EOL. I suppose they could still be around unmaintained, but who uses a
> > toolchain from 8 years in the future to build software for an EOL
> > distribution 8 years in the past? Normally it's the other way around,
> > as even glibc adds new symbols and is not forward compatible.
>
> This seems somewhat convincing to me. Would you reach out to toolchain
> maintainers to discuss this as an early change after the release of
> bookworm?

Have done so now via the gcc mailing list.

> > On the ELF interpreter, as long as we can reasonably ensure it works,
> > I do believe we should switch it, regardless of what we do with the
> > symlinks, how we ship/add/build/package/create/manage them, as a
> > desired final state. Again, we should make the default in Debian work
> > for Debian. And given the default for Debian from Bookworm onward is
> > that the loader is in /usr/lib/, it seems perfectly reasonable to me
> > that it software built for Debian and shipped in Debian should look
> > there for it.
>
> I suppose that we've been confusing the different approaches here. The
> question of what links base-files should contain mostly arises if you
> start from the assumption that we do not modify the ELF interpreter
> location. Once changing its (and /bin/sh's) location, the question of
> how to install those symlinks can indeed be done in base-files.postinst
> or at some other place where dpkg doesn't have to know much about it
> indeed. Would you agree to examine the approach where we don't modify
> the ELF interpreter location in parallel as a backup plan?

Yeah we definitely should do that. I think we should separate a bit
long-term vs short-term on that front, as it will help reach a
conclusion more quickly. I think that aspect is easy to revise, and
shouldn't lock us in a particular position one way or the other.

Kind regards,
Luca Boccassi


Reply to: