[sorry for the late reply; catching up on email]
On Fri, Feb 21, 2020 at 04:23:15PM -0500, Anthony DeRobertis wrote:
> On 2/21/20 2:00 AM, Wouter Verhelst wrote:
> > Even so, if we want to do so, this can be done correctly by a preinst
> > script in new libc, by way of a script that does the follo
* Ansgar:
> On Wed, 2020-02-19 at 09:39 +, Simon McVittie wrote:
>> On Wed, 19 Feb 2020 at 09:31:51 +, Simon McVittie wrote:
>> > I agree that what Guillem is proposing also does not have the property,
>> > which I think is one that is important to you?, that the contents of the
>> > root
On 2/21/20 2:00 AM, Wouter Verhelst wrote:
Even so, if we want to do so, this can be done correctly by a preinst
script in new libc, by way of a script that does the following:
cp -a /lib/ /usr/lib/
ln -sf /lib/ /usr/lib/
The first of the above two creates the new file; the second replaces the
Wouter Verhelst writes:
> On Wed, Feb 19, 2020 at 06:26:32AM +0100, Marco d'Itri wrote:
>> On Feb 19, Guillem Jover wrote:
>> > For any pathname that has been hardcoded a symlink can be used for
>> > backwards compat, nothing unlike /bin or /sbin here. This looks just
>> > like a normal bug from a
On Wed, Feb 19, 2020 at 06:26:32AM +0100, Marco d'Itri wrote:
> On Feb 19, Guillem Jover wrote:
>
> > For any pathname that has been hardcoded a symlink can be used for
> > backwards compat, nothing unlike /bin or /sbin here. This looks just
> > like a normal bug from a botched transition, nothin
On Wed, Feb 19, 2020 at 10:19:35AM +, Simon McVittie wrote:
> On Tue, 18 Feb 2020 at 23:20:11 +0100, Andreas Henriksson wrote:
> >a debhelper addon which runs after
> >dh_install, detects files in /lib, /bin and /sbin, moves them
> >into /usr and generates the needed postinst code d
On Wed, 2020-02-19 at 09:39 +, Simon McVittie wrote:
> On Wed, 19 Feb 2020 at 09:31:51 +, Simon McVittie wrote:
> > I agree that what Guillem is proposing also does not have the property,
> > which I think is one that is important to you?, that the contents of the
> > root directory are dec
On Tue, 18 Feb 2020 at 23:20:11 +0100, Andreas Henriksson wrote:
>a debhelper addon which runs after
>dh_install, detects files in /lib, /bin and /sbin, moves them
>into /usr and generates the needed postinst code doing the compat
>symlinks for non-merged systems.
This could work f
On Tue, 18 Feb 2020 at 22:10:05 +0100, Marco d'Itri wrote:
> On Feb 18, Simon McVittie wrote:
> > However, it doesn't give us a solution for what should happen to things
> > that are canonically on the root filesystem and *do* have their absolute
> > paths hard-coded somewhere, most critically /li
On Wed, 19 Feb 2020 at 09:31:51 +, Simon McVittie wrote:
> I agree that what Guillem is proposing also does not have the property,
> which I think is one that is important to you?, that the contents of the
> root directory are decoupled from /usr (can be set up by an initramfs
> or a container-
On Wed, 19 Feb 2020 at 06:26:32 +0100, Marco d'Itri wrote:
> Creating symlinks in /bin and /sbin DOES NOT result in a merged-/usr
> system, because the content of /usr would not be decoupled anymore from
> the content of /.
> A merged-/usr system must have /bin /sbin /lib* symlinks to /usr.
That
On Feb 19, The Wanderer wrote:
> Is there a reason this is all looking to merge /* into /usr/* instead of
> the other way around?
Yes, nicely documented by the links collected here:
https://wiki.debian.org/UsrMerge .
--
ciao,
Marco
signature.asc
Description: PGP signature
On Feb 19, Guillem Jover wrote:
> For any pathname that has been hardcoded a symlink can be used for
> backwards compat, nothing unlike /bin or /sbin here. This looks just
> like a normal bug from a botched transition, nothing special.
Creating symlinks in /bin and /sbin DOES NOT result in a merg
在 2020-02-18二的 23:58 -0500，The Wanderer写道：
> On 2020-02-18 at 20:50, Guillem Jover wrote:
>
> > On Sun, 2020-02-16 at 11:59:56 +, Simon McVittie wrote:
> >
> > > I would be grateful if people who advocate transitioning
> > > individual packages, and people who consider the approach taken by
>
On 2020-02-18 at 20:50, Guillem Jover wrote:
> On Sun, 2020-02-16 at 11:59:56 +, Simon McVittie wrote:
>
>> I would be grateful if people who advocate transitioning
>> individual packages, and people who consider the approach taken by
>> usrmerge and debootstrap to be sufficient, could refer
On Sun, 2020-02-16 at 11:59:56 +, Simon McVittie wrote:
> I would be grateful if people who advocate transitioning individual
> packages, and people who consider the approach taken by usrmerge and
> debootstrap to be sufficient, could refer to their preferred route in a
> way that makes it clea
Hello,
On Tue, Feb 18, 2020 at 10:10:05PM +0100, Marco d'Itri wrote:
> On Feb 18, Simon McVittie wrote:
>
> > No. Sorry, I phrased that badly. The consensus that I think we have is:
> > we are no longer attempting to support systems booting without /usr
> > mounted, and therefore it is not a bug
On Feb 18, Simon McVittie wrote:
> No. Sorry, I phrased that badly. The consensus that I think we have is:
> we are no longer attempting to support systems booting without /usr
> mounted, and therefore it is not a bug if programs and libraries on the
> rootfs have dependencies in /usr. (That's a
On Tue, 18 Feb 2020 at 12:44:18 +0100, Marco d'Itri wrote:
> On Feb 16, Simon McVittie wrote:
> > I think we have consensus that consolidating all static OS files into /usr
> > (removing the distinction between /usr and the static parts of the root
> > filesystem) is the route that Debian is takin
> "Marco" == Marco d'Itri writes:
>> I think we have consensus that consolidating all static OS files
>> into /usr (removing the distinction between /usr and the static
>> parts of the root filesystem) is the route that Debian is
>> taking. I think we do not have consensus on h
On Feb 16, Simon McVittie wrote:
> To be clear, what Guillem means by "a proper /usr-merged migration"
> here is changing individual library packages, so that the path to their
Everything I suppose, not just libraries.
> I think we have consensus that consolidating all static OS files into /usr
On Sat, 15 Feb 2020 at 23:21:35 +0100, Guillem Jover wrote:
> Doing a proper /usr-merged migration is what we should have done from
> the beginning. I've been doing that with all the library packages I
> maintain that were under /lib. That includes acl, attr, libaio, libbsd
> and libmd, and I know
On Sat, 15 Feb 2020 at 21:24:38 +0100, Michael Biebl wrote:
> While I think the underlying issue should be investigated (tbh the
> thought that dpkg get's confused / its db corrupted so does not properly
> clean up those old files is quite disconcerting), couldn't we just
> switch the order of /lib
On Feb 15, Guillem Jover wrote:
> > Somebody reported a similar problem about libcrypt.so.1, which moved
> > from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt).
> If the problem was with the new pathname disappearing, then that's just
> yet another instance of the usrmerge-via-sy
On Sat, 2020-02-15 at 23:27:08 +0100, Michael Biebl wrote:
> Those issues happen on non-usr-merged systems.
The one report against dpkg sure. I'm talking about the ones with
disappearing pathnames, in case that was part of "similar". But if it
was not, then libcrypt is still just broken on usrmerg
Am 15.02.20 um 23:11 schrieb Guillem Jover:
> On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote:
>> On Feb 15, Sven Joachim wrote:
>>> True, but there seem to be a relatively high number of systems where an
>>> old unowned version of some library is lying around under /lib (possibly
>>> bec
Hi!
On Sat, 2020-02-15 at 18:31:32 +0100, Andreas Metzler wrote:
> afaict we are moving to a usrmerge setup, i.e. with /lib just a
> symlink to /usr/lib. So shouldn't packages start installing stuff to
> /usr/lib instead of /lib? I would like to do that for libgcrypt, since
> I would be able to sh
On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote:
> On Feb 15, Sven Joachim wrote:
> > True, but there seem to be a relatively high number of systems where an
> > old unowned version of some library is lying around under /lib (possibly
> > because the dpkg database became corrupted at some
Am 15.02.20 um 19:48 schrieb Sven Joachim:
> True, but there seem to be a relatively high number of systems where an
> old unowned version of some library is lying around under /lib (possibly
> because the dpkg database became corrupted at some point and so dpkg
> forgot about the file; see the dp
On Feb 15, Sven Joachim wrote:
> True, but there seem to be a relatively high number of systems where an
> old unowned version of some library is lying around under /lib (possibly
> because the dpkg database became corrupted at some point and so dpkg
> forgot about the file; see the dpkg bug #949
On 2020-02-15 18:29 +, Ben Hutchings wrote:
> On Sat, 2020-02-15 at 18:31 +0100, Andreas Metzler wrote:
>> Hello,
>>
>> afaict we are moving to a usrmerge setup, i.e. with /lib just a
>> symlink to /usr/lib. So shouldn't packages start installing stuff to
>> /usr/lib instead of /lib? I would l
On Sat, 2020-02-15 at 18:31 +0100, Andreas Metzler wrote:
> Hello,
>
> afaict we are moving to a usrmerge setup, i.e. with /lib just a
> symlink to /usr/lib. So shouldn't packages start installing stuff to
> /usr/lib instead of /lib? I would like to do that for libgcrypt, since
> I would be able t
32 matches
Mail list logo
