On Fri, Aug 20, 2021 at 07:56:33AM -0600, Sam Hartman wrote:
> As you know, one of the ways we can see how close we are on consensus
> is to look at what happens when someone proposes a summary like you did.
Thanks, that was my goal: trying to see if we could move the
discussion towards some kind
tion of executables into
>> /usr by individual packages and individual packages'
>> maintainers. That's not merged-/usr: merged-/usr does the
>> migration all at once, by creating the aliasing symlinks (and
>> then we can clean up the contents of dat
where we did require a manual upgrade of dpkg first. Or
>> is my memory playing tricks on me? I do know that a manual update of
>> dpkg is the first step in a crossgrade
>
> An update to dpkg is not _required_. It might be very strongly
> _desired_ which is a perfectly leg
al update of
> dpkg is the first step in a crossgrade
An update to dpkg is not _required_. It might be very strongly
_desired_ which is a perfectly legitimate stance to take, but it is not
technically required, otherwise we couldn't have been shipping with
merged-usr as default in new insta
On Fri, 20 Aug 2021 at 09:56, Theodore Ts'o wrote:
> P.S. I had a vague memory that there was some update in the long
> distant past where we did require a manual upgrade of dpkg first. Or
> is my memory playing tricks on me? I do know that a manual update of
> dpkg is the first step in a cros
On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
>
> I think no one likes that idea, but it's the only solution that doesn't
> immediately fail because it requires a dpkg update that hasn't shipped with
> the current stable release, breaks local packages (kernel modules, firmware,
>
Hi,
On 8/19/21 4:45 PM, Theodore Ts'o wrote:
FWIW, from following the discussion, I've become more and more
convinced that a symlink farm is *not* the right answer, regardless of
whether it is done centrally or via individual packages moving files
and created symlinks if necessary in individual
On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
> In this specific case, I think the thing you're having a problem with is
> the gradual, file-by-file migration of executables into /usr by individual
> packages and individual packages' maintainers. That's n
so that individual
packages' maintainers don't have to take per-package action to move
their files from /bin,/sbin,/lib* into /usr while creating compatibility
symlinks for non-merged-/usr systems.
However, I know Guillem and some others object to that strategy, so I'm
trying to also
Hi Simon,
On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote:
> If we want to make buildd chroots merged-/usr any time soon, then I
> think we need to say this class of bugs is RC for bookworm.
I fear there might be a logic trap here.
For a moment, let us assume perfection o
On Aug 18, Simon McVittie wrote:
> I'm not sure whether there's any plan to remove the /bin, /sbin, /lib
> symlinks *ever* - things like /bin/sh are a de facto API, and the
> ELF interpreters like /lib/ld-linux.so.2 are part of their respective
> architectures' interoperable ABIs (to the extent t
On Tue, 17 Aug 2021, Sam Hartman wrote:
"Luca" == Luca Boccassi writes:
Luca> Wouldn't a pre-depends solve the ordering problem in this
Luca> case?
No.
At least it's really hard to prove that it does, we have a bad track
record of getting it wrong, and if it were to work in a
specific
On Wed, Aug 18, 2021 at 08:33:01AM +0100, Tim Woodall wrote:
> […] and time taken updating this
> script to apt "because the documentation says I should" is time I cannot
> spend on more interesting stuff (from my PoV)
For the record: The apt documentation says the opposite. /usr/bin/apt
is even a
ll out,
and 2) to update them all? There has to be one: otherwise there will be
an unspecified and unknowable large number of machines that forever
will be unable to run the proposed algorithm to switch from symlink
farm to actual usr-merged, with no path to move out of it, so the two
states will alway
---
> not to mention "#!/bin/sh" or "#!/bin/bash" as the first line in
> gazillions of scripts. So getting rid of all of compatibility
> symlinks whether done via a symlink tree or top-level symlinks for
> /bin, /sbin, /lib, etc., is probably not realistic for decade
Hi,
On 8/18/21 12:21 AM, Luca Boccassi wrote:
On Tue, 17 Aug 2021 at 20:17, Simon Richter wrote:
I agree that it's likely the only thing we can do with the version of
dpkg that we ship now, and that will have to handle the upgrade for any
users that move from one stable release to the next
On Mon, 16 Aug 2021, David Kalnischkies wrote:
/usr/bin/apt exists for 8 years now and the release notes advice using
it in every section. So, how come people are still typing apt-get
interactively to upgrade?
Best regards
David Kalnischkies
P.S.: For the avoidance of doubt: apt-get is of cou
> "Luca" == Luca Boccassi writes:
Luca> Wouldn't a pre-depends solve the ordering problem in this
Luca> case?
No.
At least it's really hard to prove that it does, we have a bad track
record of getting it wrong, and if it were to work in a
specific instance it would depend on implem
Simon,
Thanks so much for your comprehensive answer. It's a great summary
that I think would be really useful for those of us who are package
maintainers who don't have a strong position one way or another
vis-a-vis usrmerge vs merged-/usr-via-symlink-farms, but just want to
do what i
On Tue, 17 Aug 2021 at 20:17, Simon Richter wrote:
>
> Hi,
>
> On 8/17/21 8:02 PM, Simon McVittie wrote:
>
> > However, some people (most notably the dpkg maintainer, who has thought
> > about this more than most) argue that merged-/usr's "aliasing" symlinks
> > /bin -> usr/bin, etc. are unsupport
On Tue, 17 Aug 2021 at 15:08, Sam Hartman wrote:
>
> > "Luca" == Luca Boccassi writes:
>
> Luca> On Tue, 2021-08-17 at 12:07 +0200, David Kalnischkies wrote:
> Luca> If src:usrmerge is made transitively-essential, from that
> Luca> point onward it wouldn't matter if a package is n
Hi,
On 8/17/21 8:02 PM, Simon McVittie wrote:
However, some people (most notably the dpkg maintainer, who has thought
about this more than most) argue that merged-/usr's "aliasing" symlinks
/bin -> usr/bin, etc. are unsupportable, and the only correct way to
consolidate static files to be physi
re bugs.
> Suppose I released a new version of e2fsprogs targetting sid and
> bookworm which installs everything in /usr/bin, /usr/sbin, /usr/lib,
> etc, instead of splitting up files in /... and /usr/...
>
>* Is this a desirable thing to do now? (Post-bullseye release)
On Tue, Aug 17, 2021 at 05:56:15PM +0100, Simon McVittie wrote:
> tl;dr: I would prefer it if the usrmerge variation continues to be
> exercised for the testing suite for the foreseeable future.
ack, thanks (for the long version especially :) & agreed.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒
On Mon, 16 Aug 2021 16:56:34 +0200, Wouter Verhelst
wrote:
>There is pushback against having usrmerge as the "default" thing,
>because it confuses dpkg. Therefore some people would prefer a solution
>that does not require all systems to have /bin etc be symlinks unless
>and until the transition is
rue: it's more accurate to say that when *some*
> source packages are built in a merged-/usr chroot, the resulting binary
> packages don't work correctly on a non-merged-/usr system. Most source
> packages are fine either way.
>
> Such packages are already violatin
at which package maintainers will be able to assume/require that their
package is installed onto a merged-/usr system is in around 2 years' time,
*after* bookworm r0, when the bookworm+1 cycle opens in testing/unstable.
This is because the packages that make up bookworm need to be installable
o
On 2021-08-17, Holger Levsen wrote:
> On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote:
>> The failure mode we have sometimes seen is packages that were built in
>> a merged-/usr chroot not working on a non-merged-/usr system, although
>> that's detected
On Tue, 17 Aug 2021 at 08:08:15 -0600, Sam Hartman wrote:
> In order to build packages that work on a non-usrmerge system, you need
> a build chroot that is not usrmerge.
Well. That's not 100% true: it's more accurate to say that when *some*
source packages are built in a merged-
> "Luca" == Luca Boccassi writes:
Luca> On Tue, 2021-08-17 at 12:07 +0200, David Kalnischkies wrote:
Luca> If src:usrmerge is made transitively-essential, from that
Luca> point onward it wouldn't matter if a package is no longer
Luca> compatible with the legacy split-usr setup
n what a simple upgrade
> path is then; but never mind me labeling it "couldn't be much worse" as
> long as we agree it could …
>
> > still be improved by having some essential package depend on
> > "usrmerged | usrmerge" (with usrmerged being an empty
t; as
long as we agree it could …
> still be improved by having some essential package depend on
> "usrmerged | usrmerge" (with usrmerged being an empty transitional
> package which ensures that the system has a merged-/usr).
I was discussing this here with Simon already as thi
On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote:
> The failure mode we have sometimes seen is packages that were built in
> a merged-/usr chroot not working on a non-merged-/usr system, although
> that's detected by the reproducible-builds infrastructure and is alread
quot;very minor," then I think your
statement would be less likely to escalate if you'd say that.
(In this instance I suspect Debian has explicitly decided no such
thing. Implicitly I agree that we have not chosen to wait for dpkg to
get fixed before moving forward on merged /usr. For a
useful because they would negate the major benefits of
> > > merged-/usr, i.e. the ability of sharing and independently updating
> > > /usr.
> > In those cases, you would never run dpkg inside the system with the
> > "shared" /usr directory, so for those ca
On Aug 16, Wouter Verhelst wrote:
> On Fri, Aug 13, 2021 at 07:53:20AM +0200, Marco d'Itri wrote:
> > Implementations with real /bin /sbin /lib* directories and symlink farms
> > are not useful because they would negate the major benefits of
> > merged-/usr, i.e.
On Fri, Aug 13, 2021 at 10:16:57AM +0100, Luca Boccassi wrote:
> On Fri, 2021-08-13 at 07:53 +0200, Marco d'Itri wrote:
> > Implementations with real /bin /sbin /lib* directories and symlink farms
> > are not useful because they would negate the major benefits of
> > mer
On Fri, Aug 13, 2021 at 07:53:20AM +0200, Marco d'Itri wrote:
> Implementations with real /bin /sbin /lib* directories and symlink farms
> are not useful because they would negate the major benefits of
> merged-/usr, i.e. the ability of sharing and independently updating
> /usr
t "apt install usrmerge", but it could
still be improved by having some essential package depend on
"usrmerged | usrmerge" (with usrmerged being an empty transitional
package which ensures that the system has a merged-/usr).
--
ciao,
Marco
signature.asc
Description: PGP signature
On Mon, 2021-08-16 at 11:47 +0200, David Kalnischkies wrote:
> On Mon, Aug 16, 2021 at 12:59:31AM +0200, Marco d'Itri wrote:
> > BTW: the usrmerge package has been in the archive for 6 years now.
>
> /usr/bin/apt exists for 8 years now and the release notes advice using
> it in every section. So,
On Mon, Aug 16, 2021 at 12:59:31AM +0200, Marco d'Itri wrote:
> BTW: the usrmerge package has been in the archive for 6 years now.
/usr/bin/apt exists for 8 years now and the release notes advice using
it in every section. So, how come people are still typing apt-get
interactively to upgrade?
Is
On Sun, Aug 15, 2021 at 05:52:06PM +0100, Simon McVittie wrote:
> On Sun, 15 Aug 2021 at 11:52:21 +0200, David Kalnischkies wrote:
> One way out of this would be to say that it is a RC bug for packages
> in bookworm to have different contents when built in equivalent
> merged-/usr
On Aug 15, Simon McVittie wrote:
> Doing what usrmerge does from a maintainer script is pretty scary from a
> robustness/interruptability point of view. Without my Technical Committee
> hat on, one route that I think should be considered is deferring the
> migration until the next boot and doing
d to me, and you're right,
it's not ideal.
One way out of this would be to say that it is a RC bug for packages
in bookworm to have different contents when built in equivalent
merged-/usr and unmerged-/usr chroots/containers (a higher severity
than is currently applied, which I think w
supported by
> > bookworm itself…
>
> Yes, it's a little strange, but that's what happens when we don't want
> a mid-release-cycle flag day: we have to sequence things somehow. For best
> robustness for users of non-merged-/usr, build chroots should likely
> be one of
;s what happens when we don't want
a mid-release-cycle flag day: we have to sequence things somehow. For best
robustness for users of non-merged-/usr, build chroots should likely
be one of the last things to become merged-/usr, and build chroots for
suites like buster and bullseye that suppo
chroots and what not to please do it for all of them by hand
> > at a to be specified flag day someday between now and bookworm
> > freeze
>
> I think the earliest flag day that would be possible (for requiring merged
> /usr, or for completely undoing merged /usr, or for any
On Sat, Aug 14, 2021 at 02:08:33PM +0100, Luca Boccassi wrote:
> Were upgrades impossible in Ubuntu when it switched and were manual
> reinstallation mandatory for the entire user base, chroots, whatnot?
> No. Then why should it be the case for Debian if we do the exact same
> thing with the exact
ified flag day someday between now and bookworm
> freeze
That is certainly not my plan. It might be someone's plan, but it is not
one that I would support.
I think the earliest flag day that would be possible (for requiring merged
/usr, or for completely undoing merged /usr, or for any sim
On Sat, 2021-08-14 at 14:33 +0200, David Kalnischkies wrote:
> On Fri, Aug 13, 2021 at 10:16:57AM +0100, Luca Boccassi wrote:
> > Unless the intention is to deprecate allowing to change
> > /etc/apt/sources.list and mandating that only hard-coded official
> > Debian repositories can be used on Deb
On Fri, Aug 13, 2021 at 10:16:57AM +0100, Luca Boccassi wrote:
> Unless the intention is to deprecate allowing to change
> /etc/apt/sources.list and mandating that only hard-coded official Debian
> repositories can be used on Debian installations, of course, which would be,
> uh, interesting to
On Aug 13, Guillem Jover wrote:
> Yes, that major benefit that is completely broken by design and
> unsupported anyway, because /etc and /var can also easily get out
> of sync. If you rely on this then you are on your own anyway…
You say so, but it is a fact that in practice it works really well
On Fri, 2021-08-13 at 07:53 +0200, Marco d'Itri wrote:
> Implementations with real /bin /sbin /lib* directories and symlink farms
> are not useful because they would negate the major benefits of
> merged-/usr, i.e. the ability of sharing and independently updating
> /usr.
>
On Fri, 2021-08-13 at 07:53:20 +0200, Marco d'Itri wrote:
> Implementations with real /bin /sbin /lib* directories and symlink farms
> are not useful because they would negate the major benefits of
> merged-/usr, i.e. the ability of sharing and independently updating
> /usr.
Implementations with real /bin /sbin /lib* directories and symlink farms
are not useful because they would negate the major benefits of
merged-/usr, i.e. the ability of sharing and independently updating
/usr.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Tue, 2021-07-27 at 13:23:46 -0400, Calum McConnell wrote:
> > Of course, having to unnecessarily add more maintainer scripts to
> > handle something that dpkg can do perfectly fine on its own
>
> TL;DR: merged-usr-via-symlink-farms cannot be done without changing dpkg,
Hi,
On 7/27/21 7:23 PM, Calum McConnell wrote:
Of course, one could drop that to two years if you made the dpkg change a
little bit more aggressive. Since we already have dpkg creating
compatibility symlinks, why not have it also handle the file move? Simply
treat all files shipped to /{bin,sb
Am Tue, Jul 27, 2021 at 09:23:48AM -0600 schrieb Sam Hartman:
> So, even though I think the extensions to dpkg will also be complicated,
> at a purely technical level, I think they are less complicated.
>
> I understand technical complexity is only part of the picture.
> I understand the dpkg main
> Of course, having to unnecessarily add more maintainer scripts to
> handle something that dpkg can do perfectly fine on its own
TL;DR: merged-usr-via-symlink-farms cannot be done without changing dpkg,
and since the quote above seems to indicate you'd be willing to do that,
why not
On 2021-07-27 Wouter Verhelst wrote:
> On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote:
[...]
>> Afaiu you are suggesting to do somethink like this instead and
>> immediately post bulleye release.
>>
>> preinst upgrade|install
>> if aliasing
done.
I think the areas for improvement in decision making are broad here.
I'll pick examples from both sides.
During the discussion of the debootstrap decision to default to merged
/usr, several people pointed to a debian-devel thread and claimed that
thread came to a consensus in favo
On Tue, Jul 27, 2021 at 04:26:34PM +0200, Simon Richter wrote:
> Also, take care when moving shell commands from a shell script: the bash
> shell at least keeps a cache of commands to paths so it doesn't have to do a
> full path search every time. A shell script that calls
>
> mv /bin/cp /usr/
On Tue, Jul 27, 2021 at 06:53:01PM +0500, Andrey Rahmatullin wrote:
> On Tue, Jul 27, 2021 at 03:25:48PM +0200, Wouter Verhelst wrote:
> > I'm worried about systems being written to completely bypass the dpkg
> > database.
> Like alternatives and things that create files in postinst?
The alternat
that dpkg can do perfectly fine on its own, would regress
the progress we have been making to make the installation bootstrapping
automatable and definable. But that seems less worse than the breakage
induced by the merged-/usr-via-aliased-dirs layout. :/
> For debootstrap --foreign, this m
Hi,
On 7/27/21 11:44 AM, Wouter Verhelst wrote:
A package in the essential set could work around the issue by moving a
file around and creating a necessary symlink in preinst rather than
shipping things. The set of Essential packages is small however, and
most packages can ship a compat symlink
On Tue, Jul 27, 2021 at 03:25:48PM +0200, Wouter Verhelst wrote:
> I'm worried about systems being written to completely bypass the dpkg
> database.
Like alternatives and things that create files in postinst?
--
WBR, wRAR
signature.asc
Description: PGP signature
On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote:
> On 2021-07-27 Wouter Verhelst wrote:
> > On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> >> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> >>> I've suggested previously that we can easily make it
ace /usr/foo with the new version. Of course this
is all kinds of suboptimal, as the .debs will still not ship the actual
symlinks and it's trying to replicate what dpkg is designed and supposed
to do to handle Essential packages safely, even when doing this kind of
switch, where it will delay
On 2021-07-27 Wouter Verhelst wrote:
> On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
>> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
>>> I've suggested previously that we can easily make it RC for bookworm to
>>> have a file outside a limited set of directories (
On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> > I've suggested previously that we can easily make it RC for bookworm to
> > have a file outside a limited set of directories (/etc and /usr would be
> > OK, but notabl
On Thu, 2021-07-22 at 14:04 +0200, Marco d'Itri wrote:
> On Jul 22, "Barak A. Pearlmutter" wrote:
>
> > People seem pretty worked up over this, but honestly I'm not
> > understanding why.
> Because they are scared by new things, hence they oppose merged-/
On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> I've suggested previously that we can easily make it RC for bookworm to
> have a file outside a limited set of directories (/etc and /usr would be
> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> This is easy
On Mon, Jul 19, 2021 at 03:10:42PM +0200, Michael Biebl wrote:
> Hi Guillem
>
> Am 19.07.21 um 03:36 schrieb Guillem Jover:
> > What I've also said multiple times, is that
> > merged-usr-via-moves-and-symlink-farms could have been implemented in
> > a fully
[ Barak, I appreciate your mail, but *sigh*, it's still frustrating,
as pretty much many of the mails related to this, as they keep
ignoring what has been said, and I feel like talking to a wall. :/ ]
On Thu, 2021-07-22 at 11:48:34 +0100, Barak A. Pearlmutter wrote:
> Seriously? Being able to
On Jul 22, "Barak A. Pearlmutter" wrote:
> People seem pretty worked up over this, but honestly I'm not
> understanding why.
Because they are scared by new things, hence they oppose merged-/usr
(and systemd before that, and udev even before...).
But since they cannot admit
Seriously? Being able to type
dpkg -S $(which cat)
instead of
dpkg -S $(which cat|sed 's:^/usr::')
is the big user-level pain point?
People seem pretty worked up over this, but honestly I'm not
understanding why. We already have $PATH which (let's be honest) is an
ancient crappy workaround for
Andreas Metzler dixit:
>1. Make merged-/usr-via-aliased-dirs the only supported layout and make
>this information available to apt. (Like we did for multi-arch-support.)
>2. After that individual packages can safely move files from / to /usr,
>pre-depending on merged-usr-support.
Thi
t the time to light more fires on -devel.
Back to the topic of merged-/usr, the first step in any reasonable plan
to move on from the current situation - whether in favour of merged-/usr
or against it - is going to be "get Debian 11 released". So let's do that?
At this point in the
On Tue, 20 Jul 2021 23:15:33 +0200, Svante Signell
wrote:
>It is really stunning that the Debian project, including the TC
>overrides the dpkg developer and maintainer Guillem, and still using
>dpkg for package management. Maybe Debian should switch to some other
>software, like rpm-based used by
Hi,
On 2021-07-20 10:07 p.m., Brian Thompson wrote:
> On Tue, 2021-07-20 at 21:13 -0400, Polyna-Maude Racicot-Summerside
> wrote:
>> Ended up with a 3 month useless discussion regarding if this would
>> give
>> a bad impression, that we need to use node for doing development.
>> Later on I was wor
On Tue, 2021-07-20 at 21:13 -0400, Polyna-Maude Racicot-Summerside
wrote:
> Ended up with a 3 month useless discussion regarding if this would
> give
> a bad impression, that we need to use node for doing development.
> Later on I was working on a plugin that treated huge amount of data.
> So
> I i
Hi,
> Hi Holger, I would have expected a reply like this from you. I do still
> use Debian, some of my boxes are still Debian-based. Soon they will
> probably be converted to Devuan though. I do still contribute to
> Debian, mainly to Debian GNU/Hurd and Debian GNU/kFreeBSD. As long as
> these por
Hi,
On 2021-07-20 5:51 p.m., Holger Levsen wrote:
> On Tue, Jul 20, 2021 at 11:15:33PM +0200, Svante Signell wrote:
> [...]
>> Debian, the Universal Operating System was used some years ago!
>
> Svante, fine. You are unhappy with Debian since years, you're not using it
> anymore, you are not cont
Hi,
> It is really stunning that the Debian project, including the TC
> overrides the dpkg developer and maintainer Guillem, and still using
> dpkg for package management. Maybe Debian should switch to some other
> software, like rpm-based used by Fedora or even guix used by GNU?? Or
> perhaps the
On Wed, Jul 21, 2021 at 12:09:52AM +0200, Svante Signell wrote:
> Hi Holger, I would have expected a reply like this from you. I do still
> use Debian, some of my boxes are still Debian-based. Soon they will
> probably be converted to Devuan though. I do still contribute to
> Debian, mainly to Debi
On Tue, 2021-07-20 at 21:51 +, Holger Levsen wrote:
> On Tue, Jul 20, 2021 at 11:15:33PM +0200, Svante Signell wrote:
> [...]
> > Debian, the Universal Operating System was used some years ago!
>
> Svante, fine. You are unhappy with Debian since years, you're not
> using it anymore, you are no
On Tue, Jul 20, 2021 at 11:15:33PM +0200, Svante Signell wrote:
[...]
> Debian, the Universal Operating System was used some years ago!
Svante, fine. You are unhappy with Debian since years, you're not using it
anymore, you are not contributing, this is debian-devel@ not debian-rant@,
so please ST
t; > > still rescue their systems from merged-/usr-via-aliased-dirs with
> > > the aid of dpkg-fsys-usrunmess(8), see
> > > https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F
> >
> > The naming of the utility alone gi
Hi,
On 2021-07-20 3:30 p.m., Marc Haber wrote:
> On Tue, 20 Jul 2021 14:47:04 +0200, Svante Signell
> wrote:
>> According to the dpkg developer and maintainer Guillem users can still
>> rescue their systems from merged-/usr-via-aliased-dirs with the aid of
>> dpk
On Tue, 20 Jul 2021 14:47:04 +0200, Svante Signell
wrote:
>According to the dpkg developer and maintainer Guillem users can still
>rescue their systems from merged-/usr-via-aliased-dirs with the aid of
>dpkg-fsys-usrunmess(8), see
>https://wiki.debian.org/Team
On Tue, 2021-07-20 at 13:41 +0200, Andreas Metzler wrote:
>
> Hello,
> Isn't this kind of crying over spilt milk? I also wish we never had
> ended up with the buster/bullseye state where both unmerged and
> merged-/usr-via-aliased-dirs are fully supported. However there is
&g
ackages to move their files from
>> /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we already have a
>> debhelper patch to do that move for us?
> Unfortunately, when the supporters of the merged-/usr-via-aliased-dirs
> pushed their approach into the distribution, that meant th
On Tue, 2021-07-20 at 11:31:37 +0200, Guillem Jover wrote:
> Unfortunately, when the supporters of the merged-/usr-via-aliased-dirs
> pushed their approach into the distribution, that meant that package
> stopped being able to ship compatibility symlinks under «/», and those
>
ib)/ to /usr/(sbin|bin|lib)/ or do we
> already have a debhelper patch to do that move for us?
Unfortunately, when the supporters of the merged-/usr-via-aliased-dirs
pushed their approach into the distribution, that meant that package
stopped being able to ship compatibility symlinks under «/», and
On Mon, 2021-07-19 at 15:10:42 +0200, Michael Biebl wrote:
> Am 19.07.21 um 03:36 schrieb Guillem Jover:
> > What I've also said multiple times, is that
> > merged-usr-via-moves-and-symlink-farms could have been implemented in
> > a fully automated way, by debhelper, w/
k things. I will be sticking to "targeted" migrations where
the major consumers have informed me that they are ready to support the
migration.
>> [...]
>>
>> Once we have this global switch to merged-usr, packages can bit by bit,
>> completely independent, update thei
On Mon, 19 Jul 2021 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote:
> Should I rather file bugs with patches against individual packages
> to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/
As discussed in previous iterations of the ongoing merged-/usr megathr
On Mon, 19 Jul 2021 15:19:32 +0200, Michael Biebl
wrote:
>Am 19.07.21 um 07:23 schrieb Marc Haber:
>> I am NOT looking forward having to manually convert legacy systems to
>> merged /usr and I do sincerely hope that Debian will choose a way to
>> get away without throwing a
Quoting Michael Biebl (2021-07-19 15:10:42)
> Am 19.07.21 um 03:36 schrieb Guillem Jover:
> > What I've also said multiple times, is that
> > merged-usr-via-moves-and-symlink-farms could have been implemented in
> > a fully automated way, by debhelper, w/o requiring any m
Am 19.07.21 um 07:23 schrieb Marc Haber:
I am NOT looking forward having to manually convert legacy systems to
merged /usr and I do sincerely hope that Debian will choose a way to
get away without throwing away systems that have just a small /, still
supporting a dedicated /usr as long as it&#
201 - 300 of 677 matches
Mail list logo
