Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

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 automated way, by debhelper, w/o requiring any maintainer scripts, all with full cooperation and managed by dpkg

Re: merged /usr

On Mon, 19 Jul 2021 at 11:33:49 +0200, Stephan Lachnit wrote: > We could start with collecting the packages that install to /bin* > instead of /usr/bin, and adjust the packaging so that they don't do > that. [...] At this point, it shouldn't > matter if you run a merged usr system or

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Mon, Jul 19, 2021 at 3:37 AM Guillem Jover wrote: > 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 maintainer scripts, > all with full cooperation and man

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Jul 19, Marc Haber wrote: > 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

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

As I said, on a separate mail... Marc Haber dijo [Mon, Jul 19, 2021 at 07:12:24AM +0200]: > In an ideal world, would the package manager not be a service utility > to SUPPORT policy and adapt to changing environment contitions instead > being a showstopper for innovation? > > Who is the dpkg

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Sorry to single you out here, Marc -- This goes to many people. This goes, in fact, to the discussion itself. Marc Haber dijo [Mon, Jul 19, 2021 at 07:12:24AM +0200]: > In an ideal world, would the package manager not be a service utility > to SUPPORT policy and adapt to changing environment

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Nowadays you can also have BTRFS subvolumes, which does not require you to define sizes in advance. In that case it is nice for snapshotting to have separate subvolumes for things like home directories. Regards

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

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's mounted by initramfs. I am not sure whether

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

eliability (from 3rd-party repos >or locally built packages, etc, f.ex.). I must be missing some thing, but isn't it the experienced admins facing reinstalls of vital systems when we finally move to a completely merged /usr, because these usually currently have /usr on a dedicated mountpoint? >Because t

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Polyna-Maude Racicot-Summerside writes: > I had the belief that some software used /tmp for temporary file that > may grow many GB (example DVD creation). > I have 32 GB It should not, or at least it should let you specify a different path, because using tmpfs for /tmp is very common these

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Thu, 2021-07-15 at 10:13:47 +0100, Luca Boccassi wrote: > As it has been said and written many times already, in reality this is > not broken by design at all and in fact it is the only successful > strategy that has been deployed by other distros - it's what is being > called me

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Hi, On 2021-07-18 7:21 p.m., Russ Allbery wrote: > Polyna-Maude Racicot-Summerside writes: > >> Here's my actual config (with 2TB) and yes I have a separate /home > >> What is tmpfs and why is it set to 3.2 GB ? > > tmpfs is a RAM-backed temporary file system that is automatically used for >

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

unclear to me why you've taken my reply to your mail on debian-user, and instead sent it to me privately and also to debian-devel. As neither of us are Debian Developers and you don't seem to have done much research regarding merged-/usr, I don't feel it is on-topic for me to continue that con

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Russ Allbery writes: > I see that you have your system configured to store /tmp on your disk. > This is generally not recommended these days. Storing /tmp in tmpfs is > much faster for some applications and automatically achieves the desired > and standard /tmp behavior of clearing it on

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Svante Signell writes: > Again, everybody is just hiding, I wonder from who, the big wolf?? Who > is hen? Anybody having the courage to reply to this list about this > issue, not only workarounds/diversions? I'm not discussing the issue on the list because I think the current direction in

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Polyna-Maude Racicot-Summerside writes: > Here's my actual config (with 2TB) and yes I have a separate /home > What is tmpfs and why is it set to 3.2 GB ? tmpfs is a RAM-backed temporary file system that is automatically used for paths like /run and /dev/shm that are supposed to be cleared on

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Hi, On 2021-07-18 6:17 p.m., Marco d'Itri wrote: > On Jul 19, Polyna-Maude Racicot-Summerside wrote: > >> So if I get it right... > Except for /boot/, which may be required for technical reasons, there > is no need to further partition your file system unless you actually > have reasons to do

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Sun, 2021-07-18 at 20:58 +0200, Svante Signell wrote: > On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote: > > On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote: > > > Sean Whitton dixit: > > > > * #978636 move to merged-usr-only? > > > >

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Jul 19, Polyna-Maude Racicot-Summerside wrote: > So if I get it right... Except for /boot/, which may be required for technical reasons, there is no need to further partition your file system unless you actually have reasons to do it. > One partiton for /boot > One partition for /usr > One

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Hello (Hi) ! On 2021-07-18 5:07 p.m., Andy Smith wrote: > Hello, > > I think all of this is quite clearly explained in: > > https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian > > which is linked from: > > https://wiki.debian.org/UsrMerge > > If you think it's not

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

upported Debian tools like initramfs-tools or dracut, which you > will do unless you have gone out of your way to do something > different. > I've did many Debian install, using the standard installation software, creating those partition from the "expert" choice of install mode. And

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Hi, On 2021-07-18 5:31 p.m., Svante Signell wrote: > Hi, is it OK to forward your mail to debian-devel. I don't think > mailing to debian-user will have any effect on this issue? > Sure ! Honestly it's my mistake to have sent it to debian-user. I get everything in one mailbox. I need to have

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Fri, Jul 16, 2021 at 01:15:37PM +0200, Magissia wrote: > In this case, this page should be updated to reflect the fact it is not > broken. > > https://wiki.debian.org/Teams/Dpkg/MergedUsr Logic does not quite work that way. Just because we selected that way of doing things doesn't imply it

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote: > On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote: > > Sean Whitton dixit: > > > * #978636 move to merged-usr-only? > > > > > > We were asked to decide whether or not Debian 'bookworm' shoul

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Sun, Jul 18, 2021 at 10:11:22PM +0500, Andrey Rahmatullin wrote: > While, AFAIK, it's indeed only Debian Policy stopping you from not > shipping /usr/share/doc/*/copyright, and that and common sense stopping > you from not shipping /usr/share/doc/*/changelog, that's just yet another > case of

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Sun, Jul 18, 2021 at 04:50:49PM +, Stephan Verbücheln wrote: > Thank you for the explanation. I think it covers most use cases. > However, it does not cover packages that do not actually install > programs but only perform changes to /etc or install something to /opt, > is that correct?

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Thank you for the explanation. I think it covers most use cases. However, it does not cover packages that do not actually install programs but only perform changes to /etc or install something to /opt, is that correct? Regards

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Jul 18, Stephan Verbücheln wrote: > On Sun, 2021-07-18 at 11:13 +0200, Marco d'Itri wrote: > > I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is > > > What? No matter whether we merge “/bin” or not, “/usr” should stay > read-only. The dpkg database IS read-only as long as

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Sun, Jul 18, 2021 at 11:09:49AM +, Stephan Verbücheln wrote: > On Sun, 2021-07-18 at 11:13 +0200, Marco d'Itri wrote: > > I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is > > > > What? No matter whether we merge “/bin” or not, “/usr” should stay > read-only. On Debian

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Sun, 2021-07-18 at 11:13 +0200, Marco d'Itri wrote: > I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is > What? No matter whether we merge “/bin” or not, “/usr” should stay read-only. Regards

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Sun, Jul 18, 2021 at 11:13:37AM +0200, Marco d'Itri wrote: > On Jul 18, Simon McVittie wrote: > > If a machine's /usr is not in sync with its /etc and /var, then it is likely > > to work incorrectly: at a minimum, asking dpkg which packages and versions > But in my experience (with shared-/usr

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Jul 18, Simon McVittie wrote: > If a machine's /usr is not in sync with its /etc and /var, then it is likely > to work incorrectly: at a minimum, asking dpkg which packages and versions But in my experience (with shared-/usr containers) this works great as long as everything is aligned to

Re: merged /usr considered harmful

Summary: let go, let go On Sat, Jul 17, 2021 at 09:13:57PM +, Thorsten Glaser wrote: > > And no, I’m not going to embrace every unnecessary change thrown my way. None of us does embraces every unnecessary change. We all choose our battles wisely. > No; usrmerge is broken from the PoV of

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

hether merged-/usr is used or not, but only if /usr is already mounted by the time the system hands over from the initramfs (usually generated by initramfs-tools, or sometimes dracut or another alternative) to the main system (which starts systemd, sysvinit or some other init system as the main

Re: merged /usr considered harmful

Johannes Drexl dixit: >embrace getting rid of /sbin and /bin. FHS 3.0 explicitely states that >/usr is allowed to be not only on a separate partition, but even on a >network device shared by other machines: This hasn’t been true on Debian for a while (partially due to the systemd/usrmerge

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Am Freitag, dem 16.07.2021 um 10:09 +0200 schrieb Thomas Goirand: > Merging binaries in /usr and getting rid of /bin and /sbin, at the > end, > WILL be an improvement. Debian cannot be the last distro not doing > the > move, I hope you understand that. > > Also, I'm having a hard time

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

:56 +, Thorsten Glaser wrote: > > > Sean Whitton dixit: > > > > * #978636 move to merged-usr-only? > > > > > > > > We were asked to decide whether or not Debian 'bookworm' > > > > should > > > > continue to support syst

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On 7/16/21 10:09 AM, Thomas Goirand wrote: > On 7/14/21 9:54 PM, Thorsten Glaser wrote: >> Sean Whitton dixit: >> >>> * #978636 move to merged-usr-only? >>> >>> We were asked to decide whether or not Debian 'bookworm' should >>> continue to

Re: merged /usr considered harmful

Thorsten Glaser writes: >>But in any case, given that merged-usr-via-aliased-dirs is not really >>supported by dpkg anyway, it is broken by design [B], I have no > > Time for another GR? Leaving Debian behind? Threats of leaving are not fine and are just making any discus

Re: merged /usr considered harmful

On 2021-07-16 at 03:18, Marc Haber wrote: > On Fri, 16 Jul 2021 01:44:54 + (UTC), Thorsten Glaser > wrote: > >>Marc Haber dixit: >> >>>think we can afford an additional time sink at the moment. Please, get >> >>While that’s true… > > You conveniently snipped the "I don't" which turns your

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On 7/14/21 9:54 PM, Thorsten Glaser wrote: > Sean Whitton dixit: > >> * #978636 move to merged-usr-only? >> >> We were asked to decide whether or not Debian 'bookworm' should >> continue to support systems which are not using the merged-usr >> filesystem lay

Re: merged /usr considered harmful

eport ☹ > >> But in any case, given that merged-usr-via-aliased-dirs is not really >> supported by dpkg anyway, it is broken by design [B], I have no > > Time for another GR? Please don't! This isn't funny... Thomas

Re: merged /usr considered harmful

On Fri, 16 Jul 2021 01:44:54 + (UTC), Thorsten Glaser wrote: >Marc Haber dixit: >>think we can afford an additional time sink at the moment. Please, get > >While that’s true… You conveniently snipped the "I don't" which turns your quote into the opposite that I wanted to say. Greetings Marc

Re: merged /usr considered harmful

Marc Haber dixit: >think we can afford an additional time sink at the moment. Please, get While that’s true… >Can we please delay this discussion until after the release? I don't … we can’t afford to: the TC discussion becomes valid as soon as bullseye is released, which is in two weeks, and

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Hello, On Thu 15 Jul 2021 at 09:56AM +02, Jonathan Carter wrote: > Hi Sean > > On 2021/07/15 09:04, Sean Whitton wrote: >> Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean >> what I would get if I typed 'debootstrap bullseye /foo', ri

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On 2021/07/15 10:47, Marc Haber wrote: > Can we please delay this discussion until after the release? To be clear, I was requesting further details from the TC, not a re-evaluation or further discussion. -Jonathan

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote: > On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote: > > Sean Whitton dixit: > > > * #978636 move to merged-usr-only? > > > > > > We were asked to decide whether or not Debian 'bookworm' shoul

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Thu, 15 Jul 2021 09:56:18 +0200, Jonathan Carter wrote: >On 2021/07/15 09:04, Sean Whitton wrote: >> Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean >> what I would get if I typed 'debootstrap bullseye /foo', right? >> >> I would

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Hi Sean On 2021/07/15 09:04, Sean Whitton wrote: > Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean > what I would get if I typed 'debootstrap bullseye /foo', right? > > I would like to note that the TC decision did not specify any particular > impl

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

Hello Guillem, On Wed 14 Jul 2021 at 11:40PM +02, Guillem Jover wrote: > On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote: >> Sean Whitton dixit: >> >* #978636 move to merged-usr-only? >> > >> > We were asked to decide whether or not Debian 'bookwo

Re: merged /usr considered harmful

Guillem Jover dixit: >I've been meaning to send a note about this for some time now, but >as I feel it keeps getting ignored, it always seems a bit pointless. Yeah, I saw this popping up multiple times in that bugreport ☹ >But in any case, given that merged-usr-via-aliased-dirs is n

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote: > Sean Whitton dixit: > >* #978636 move to merged-usr-only? > > > > We were asked to decide whether or not Debian 'bookworm' should > > continue to support systems which are not using the merged-usr > >

merged /usr considered harmful (was Re: Bits from the Technical Committee)

Sean Whitton dixit: >* #978636 move to merged-usr-only? > > We were asked to decide whether or not Debian 'bookworm' should > continue to support systems which are not using the merged-usr > filesystem layout. We decided that support should not continue beyond > Debian

Re: move to merged-usr-only?

On Thu, 21 Jan 2021 at 06:03:52 +0100, Guillem Jover wrote: > I mentioned this before, this does not look specific to whatever > method to do merged-/usr, instead this seems like a general dpkg > problem related to missing fsync() on the directories during unpacks It's great news that so

Re: move to merged-usr-only?

42AM +0100, Ansgar wrote: > > > > As far as I know nothing broke catastrophically over the last releases > > > > with merged-/usr. > > > > > > Unless you look at dpkg or attempts at speeding up bootstrap. > > >

Re: Bug#978636: move to merged-usr-only?

On Jan 02, Matthias Klumpp wrote: > You wouldn't have to depend on PackageKit, the offline-upgrades stuff > can be implemented by other tools that aren't PK as well (you could > pretty much use the same mechanism, with some safeguards to not > interfere with PK/GNOME). However, ensuring that no

Re: Bug#978636: move to merged-usr-only?

Am Di., 29. Dez. 2020 um 23:13 Uhr schrieb Marco d'Itri : > > On Dec 29, Matthias Klumpp wrote: > > > For package upgrades, we can already perform so-called "offline > > upgrades", where the system reboots into a smaller systemd target, > > applies all updates and then reboots again into the

Re: Bug#978636: move to merged-usr-only?

On Tue, 2020-12-29 at 23:12 +0100, Marco d'Itri wrote: [...] > I think that depending on PackageKit would be more complex than an > initramfs-tools hook, since just about everybody is supposed to have > that around. I'm afraid not - dracut, tiny-initramfs, and custom kernels that don't need an

Re: Bug#978636: move to merged-usr-only?

On Dec 29, Matthias Klumpp wrote: > For package upgrades, we can already perform so-called "offline > upgrades", where the system reboots into a smaller systemd target, > applies all updates and then reboots again into the updated system. > This is implemented in PackageKit as an option and used

Re: Bug#978636: move to merged-usr-only?

Am Di., 29. Dez. 2020 um 17:39 Uhr schrieb Marco d'Itri : > > On Dec 29, Ansgar wrote: > > > as suggested in [1], I would like to see Debian to move to support > > only the merged-usr filesystem layout. This would simplfy things for > > the future and also address

Re: Bug#978636: move to merged-usr-only?

On Dec 29, Ansgar wrote: > as suggested in [1], I would like to see Debian to move to support > only the merged-usr filesystem layout. This would simplfy things for > the future and also address the problem with installing files under > aliased trees that dpkg has to do for b

Bug#978636: move to merged-usr-only?

Package: tech-ctte X-Debbugs-Cc: debian-devel@lists.debian.org Hi, as suggested in [1], I would like to see Debian to move to support only the merged-usr filesystem layout. This would simplfy things for the future and also address the problem with installing files under aliased trees that dpkg

Re: move to merged-usr-only?

Andreas Metzler wrote... > I am all for declaring a cutoff date (and release) which makes usrmerge > mandatory and the only supported setup. (Or alternatively make usrmerge > an unsupported setup.) The current state where we are trying to support > both and end up dealing with fallout and cannot

Re: move to merged-usr-only?

On 2020-11-20 Ansgar wrote: > I would like to propose to plan to move to support merged-usr-only over > the following releases. The motivation is bugs like [1] where upstream > developers just use `/usr/bin/rm` (or other binaries, or user scripts > using /usr/bin/bash, or ...) unc

Re: move to merged-usr-only?

en people using `#!/bin/python` as interpreter a long time ago (before Debian had merged-/usr by default). One can try to educate people that this is wrong because some binaries were historically only available in /usr (due to too small root disk, but a larger disk for /home), but why bother when we c

Re: move to merged-usr-only?

On Sat, Nov 21, 2020 at 10:33 AM Ansgar wrote: > The goal is to have /bin and /usr/bin to have identical contents. > So one would need a new /bin/python3 -> /usr/bin/python3 symlinks Those seem unnecessary to me, since we have $PATH and nothing should be using /bin/python3 at this stage. --

Re: move to merged-usr-only?

aybe[2] start *another* *multi-year) migration after that, and then getting there isn't a great outlook for me. (At that time migration to merged-/usr for the remaining systems would no longer be a worry either way as presumably only very few installations without merged-/usr would exist anyway an

Re: move to merged-usr-only?

On Fri, Nov 20, 2020 at 7:35 PM Simon McVittie wrote: > Package-by-package migration touches a large number of packages By my count there are 1712 binary packages from X source packages installing things outside /etc /usr /var $ apt-file search --regexp '^/[^euv]' | sed 's/: .*//' | sort -u |

Re: move to merged-usr-only?

On Fri, 20 Nov 2020 at 11:12:20 +0100, Ansgar wrote: > On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote: > > On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote: > > > As far as I know nothing broke catastrophically over the last releases > > > with merged-/us

Re: move to merged-usr-only?

On Fri, 2020-11-20 at 09:35 +0100, Ansgar wrote: > Hi, > > I would like to propose to plan to move to support merged-usr-only over > the following releases. The motivation is bugs like [1] where upstream > developers just use `/usr/bin/rm` (or other binaries, or user scripts &

Re: move to merged-usr-only?

On Fri, 2020-11-20 at 11:12 +0100, Ansgar wrote: > On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote: > > So let's make it so a canonical path to a file never includes a directory > > symlink; if you insist on /usr/bin/rm then /bin/rm should be > > /bin/{rm->/usr/bin/rm} not

Re: move to merged-usr-only?

On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote: > On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote: > > I would like to propose to plan to move to support merged-usr-only over > > the following releases. The motivation is bugs like [1] where upstream > > deve

Re: move to merged-usr-only?

On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote: > I would like to propose to plan to move to support merged-usr-only over > the following releases. The motivation is bugs like [1] where upstream > developers just use `/usr/bin/rm` (or other binaries, or user scripts > using /

move to merged-usr-only?

Hi, I would like to propose to plan to move to support merged-usr-only over the following releases. The motivation is bugs like [1] where upstream developers just use `/usr/bin/rm` (or other binaries, or user scripts using /usr/bin/bash, or ...) unconditionally; this was already a motivation

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

On Sun, 2019-02-24 at 03:23:09 +0100, Guillem Jover wrote: > On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote: […] > > - file a bug on base-installer to request an option to install > > non-broken systems due to merged-/usr-via-symlinks. > > Done. <https:

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

Julian Andres Klode writes: > Having symlinks in /bin and so on would be unclean: We'd have to maintain > one symlink per binary in /usr. This is a lot of symlinks. Does the quantity of symlinks matter? > We also cannot ever get rid of them - it would break the property. Well, on any given

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

> > So, people still seem to be conflating merged-/usr (the filesystem > layout) with the different ways to deploy it. Personally I do agree > that merged-/usr has benefits, and that's why I've f.ex. been switching > the shared library packages I maintain to do a proper and correc

Re: merged-/usr-via-symlinks vs a-different-layout

e underlying concept. And not about how it is Guillem> important to me. Guillem> Sure (even though that was unrelated to my point), and I've Guillem> acknowledged that in previous threads. I do understand some Guillem> people might value using a deployment method that

Re: merged-/usr-via-symlinks vs a-different-layout

ng concept. And not about how it is important to me. > Other things are important to other people. Sure (even though that was unrelated to my point), and I've acknowledged that in previous threads. I do understand some people might value using a deployment method that gives immediate results so

Re: merged-/usr-via-symlinks vs a-different-layout

> "Guillem" == Guillem Jover writes: Guillem> On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote: >> Guillem Jover writes: > You are still conflating the concept with >> the deployment. The > underlaying properties of merging /usr is >> that the contents for > directories

Re: merged-/usr-via-symlinks vs a-different-layout

ployments is how the move is done, and how and which compat symlinks are setup. > I can come up with other variations that move files to /usr too: have > /bin a symlink to /usr/root/bin (some for other directories). That > would also be a different file system layout which shouldn't be c

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

gt; - include a bug-script in dpkg for reportbug to report whether the > > system has been broken by the merged-/usr-via-symlinks hack. > > Done. > > > - file a bug on reportbug to request reporting that for all packages. > > Done. <https://bugs.debian.org/923090> &g

Re: merged-/usr-via-symlinks vs a-different-layout

Guillem Jover writes: > On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote: >> Guillem Jover writes: >> > 3) Switching packages to the merged-/usr layout could have been >> >accomplished automatically via debhelper for a coverage of around >> >99% (?)

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

n by the merged-/usr-via-symlinks hack. Done. > - file a bug on reportbug to request reporting that for all packages. Done. <https://bugs.debian.org/923090> > - file a bug on base-installer to request an option to install > non-broken systems due to merged-/u

Re: merged-/usr-via-symlinks vs a-different-layout

On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote: > Guillem Jover writes: > > 3) Switching packages to the merged-/usr layout could have been > >accomplished automatically via debhelper for a coverage of around > >99% (?) of the archive. With some

Re: merged-/usr-via-symlinks vs a-different-layout

Guillem Jover writes: > 3) Switching packages to the merged-/usr layout could have been >accomplished automatically via debhelper for a coverage of around >99% (?) of the archive. With something along the lines of: > > ,--- > D=debian/tmp > for d i

merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

Hi! On Tue, 2018-11-20 at 22:16:17 +0100, Adam Borowski wrote: > Thus, it seems to me that the plan A for usrmerge has serious downsides for > dubious benefits. What about the plan B I described above? So, people still seem to be conflating merged-/usr (the filesystem layout) with the dif

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Package: debootstrap Version: debootstrap/1.0.110 Severity: serious Merged /usr is now the default in buster. As discussed on debian-devel, however, binary packages built on a merged-usr system are not installable on a non-merged-usr system. I think we would like ad hoc builds of packages from

Bug#914898: debootstrap, stretch-backports: Please disabled merged /usr by default

Package: debootstrap Version: debootstrap/1.0.110~bpo9+1 Severity: serious In #914208 Simon McVittie writes: > [merge-/usr] is now the default in stretch-backports' debootstrap As discussed on debian-devel, however, binary packages built on a merged-usr system are not installable on a non-mer

Re: Bug#843073: dpkg-shlibdeps fix for merged /usr

On Mon, 2016-12-12 at 04:26:20 +0100, Marco d'Itri wrote: > On Nov 21, Guillem Jover wrote: > > First I have to go over a list of queued pending items and then I'll > > get to this during this week. I have not yet reviewed the patches (in > > part because I didn't do much

Re: Bug#843073: dpkg-shlibdeps fix for merged /usr

On Nov 21, Guillem Jover wrote: > First I have to go over a list of queued pending items and then I'll > get to this during this week. I have not yet reviewed the patches (in > part because I didn't do much Debian stuff last week due to lack of > motivation after an

Re: Issues when building armhf packages in sid chroot with merged-usr

On Nov 10, Uwe Kleine-König wrote: > I tried to build the experimental linux package on an armhf machine > using sbuild. It failed (after 7 hours, sigh) with: This looks like #843073. -- ciao, Marco signature.asc Description: PGP signature

Issues when building armhf packages in sid chroot with merged-usr

Hello, I tried to build the experimental linux package on an armhf machine using sbuild. It failed (after 7 hours, sigh) with: dpkg-shlibdeps: error: no dependency information found for /usr/lib/ld-linux-armhf.so.3 (used by

Re: Support for merged-/usr now in debootstrap; default for stretch?

On Tue, 2016-09-27 at 15:42 +0500, Andrey Rahmatullin wrote: > On Tue, Sep 13, 2016 at 10:36:58PM +0200, Ansgar Burchardt wrote: > > > > debootstrap in unstable can now install with merged-/usr, that is > > with > > /bin, /sbin, /lib* being symlinks to their co

Re: Support for merged-/usr now in debootstrap; default for stretch?

On Tue, Sep 13, 2016 at 10:36:58PM +0200, Ansgar Burchardt wrote: > debootstrap in unstable can now install with merged-/usr, that is with > /bin, /sbin, /lib* being symlinks to their counterpart in /usr. Run > > debootstrap --merged-usr testing .../testing http://deb.debia

Re: Support for merged-/usr now in debootstrap; default for stretch?

mebody would have complained about the lack of an opt-out mechanism. Since merged-/usr has significant benefits and is the scheme used RHEL/Centos/Fedora I think that it should be the default for us as well. -- ciao, Marco signature.asc Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

On Sep 15, Adam Borowski wrote: > I think it would be worthwhile to split up and move parts of /var as well. This is out of scope for this thread, so please let's discuss your proposals at a different time. -- ciao, Marco signature.asc Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

s in / and parts in /usr and your mount > options only apply to the bits in /usr. > A fully read-only system is actually much simpler with the merged-usr setup. I think it would be worthwhile to split up and move parts of /var as well. It is a big mess of distinct stuff: * parts of packagi

Re: Support for merged-/usr now in debootstrap; default for stretch?

On Sep 14, Ansgar Burchardt <ans...@debian.org> wrote: > One can also test installations using d-i.  The images from [1] already Just to be clear: merged-/usr can be tested on an existing system by installing the usrmerge package. -- ciao, Marco signature.asc Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

ctually much simpler with the merged-usr setup. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature

<    1   2   3   4   5   6   7   >