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.

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?)

On Tue, Feb 19, 2019 at 05:49:24AM +0100, Guillem Jover wrote: > 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

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: > > So, as part of damage control I'm going to: > > > > - include the Build-Tainted-By patches into dpkg 1.19.5. > > Done. > > > - include a bug-script in dpkg for

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

Hi! On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote: > So, as part of damage control I'm going to: > > - include the Build-Tainted-By patches into dpkg 1.19.5. Done. > - include a bug-script in dpkg for reportbug to report whether the > system has been broken by the

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 different

Re: Tainted builds (was Re: usrmerge -- plan B?)

Guillem Jover writes: > So I think I'll go ahead with the current name for now, it's going to be > an optional field anyway, so if there's a better name proposed that > conveys a satisfactory meaning, I'll be happy to consider it and do a > rename, and handle any users of the current name. Why

Re: Tainted builds (was Re: usrmerge -- plan B?)

e kernel, but that does not mean that, say, an oops, was caused by that. And when it comes to the merged-usr-via-symlinks tag, I actually think that tainted is really an understatement. On Wed, 2018-12-05 at 13:35:36 +0000, Ian Jackson wrote: > Russ Allbery writes ("Re: Tainted builds (was

Re: usrmerge -- plan B?

Martin Steigerwald wrote: > Marco d'Itri - 23.12.18, 22:30: >> On Dec 23, Martin Steigerwald wrote: >>> I think I have seen this with either SLES or RHEL that they created >>> symlinks for every binary in /bin and /sbin, pointing to the binary >>> in /usr/bin and /usr/sbin. I did not understand

Re: usrmerge -- plan B?

Marco d'Itri - 23.12.18, 22:30: > On Dec 23, Martin Steigerwald wrote: > > I think I have seen this with either SLES or RHEL that they created > > symlinks for every binary in /bin and /sbin, pointing to the binary > > in /usr/bin and /usr/sbin. I did not understand why at the time I > > have

Re: usrmerge -- plan B?

On Dec 23, Martin Steigerwald wrote: > I think I have seen this with either SLES or RHEL that they created > symlinks for every binary in /bin and /sbin, pointing to the binary in > /usr/bin and /usr/sbin. I did not understand why at the time I have seen > this. Definitely not RHEL, maybe you

Re: usrmerge -- plan B?

Guillem Jover - 23.12.18, 17:17: > On Sun, 2018-12-23 at 16:45:28 +0100, Guillem Jover wrote: > > On Sun, 2018-12-23 at 04:06:14 +0100, Guillem Jover wrote: > > > […] They also imply to permanently suffer the aliasing problems. > > > > To expand and clarify a bit on this. We have aliasing in

Re: usrmerge -- plan B?

On Sun, 2018-12-23 at 16:45:28 +0100, Guillem Jover wrote: > On Sun, 2018-12-23 at 04:06:14 +0100, Guillem Jover wrote: > > […] They also imply to permanently suffer the aliasing problems. > > To expand and clarify a bit on this. We have aliasing in general with > symlinks and hardlinks, but

Re: usrmerge -- plan B?

On Sun, 2018-12-23 at 04:06:14 +0100, Guillem Jover wrote: > […] They also imply to permanently suffer the aliasing problems. To expand and clarify a bit on this. We have aliasing in general with symlinks and hardlinks, but those tend to not be as problematic when aliasing the last component, as

Re: usrmerge -- plan B?

On Dec 23, Guillem Jover wrote: > To me it's always been very clear the only *proper* way to deploy > merged-/usr, is to do the changes to the canonical pathnames on > each relevant package. Even adding compat symlinks, means that dpkg > would know about them, and they'd be temporary anyway for

Re: usrmerge -- plan B?

Hi! On Mon, 2018-12-03 at 18:22:03 -0800, Russ Allbery wrote: > Guillem Jover writes: > > The current merged-/usr deployment (via usrmerge or the bootstrapping > > symlink generation before unpack) is a major hack, and bypasses the dpkg > > understanding of the filesystem, it breaks dpkg-query,

Re: Tainted builds (was Re: usrmerge -- plan B?)

Russ Allbery writes ("Re: Tainted builds (was Re: usrmerge -- plan B?)"): > Tainted is a loaded term that may make this more confusing. Can we think of a better term before `taint' gets embedded ? It's going to be annoying if we have to have an argument every time we want to

Re: Tainted builds (was Re: usrmerge -- plan B?)

Guillem Jover writes ("Re: Tainted builds (was Re: usrmerge -- plan B?)"): > I think I'm still of the opinion that a user should be able to build on > a normal (clean and up-to-date) system and get a proper result. I guess > the problem might be how to define "clean".

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Tue, Dec 04, 2018 at 01:07:42AM +0100, Guillem Jover wrote: > These will detect problematic files under /usr/local which can taint > the current build. [...] > +.B usr\-local\-has\-programs I regularily have stuff in /usr/local/(s)bin/ which does not taint the system nor my builds, so I think

Re: usrmerge -- plan B?

On Dec 04, Russ Allbery wrote: > Does this imply that you're considering adding support for merging /usr > *properly* directly inside dpkg, with all the correct updates to dpkg's > metadata? > > Because that would be an awesome way to fully support this. It would make using dpkg -S a bit easier

Re: usrmerge -- plan B?

Guillem Jover writes: > The current merged-/usr deployment (via usrmerge or the bootstrapping > symlink generation before unpack) is a major hack, and bypasses the dpkg > understanding of the filesystem, it breaks dpkg-query, and while we > could workaround the breakage there, it's still the

Re: Tainted builds (was Re: usrmerge -- plan B?)

Guillem Jover writes: > … and then I'm not entirely sure a non-minimal environment should be > qualified as tainted? For example contrast using a minimal but outdated > installation to a non-minimal, but clean and up-to-date one. > I think I'm still of the opinion that a user should be able to

Re: usrmerge -- plan B?

On Sun, 2018-12-02 at 13:40:05 +0200, Niko Tyni wrote: > On Fri, Nov 23, 2018 at 04:32:17PM +0100, Guillem Jover wrote: > > Please, if we decide we want to do merged /usr, let's do it properly. > > I'm toying with the idea of creating a merged-usr package indicating > 'this system has merged

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Mon, 2018-12-03 at 16:45:15 -0500, Michael Stone wrote: > On Sun, Dec 02, 2018 at 04:28:46PM -0800, Russ Allbery wrote: > > Guillem Jover writes: > > > Whether a package is being built within a chroot or not, has nothing > > > to do with how that installation is being managed IMO. It feels a

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Sun, Dec 02, 2018 at 04:28:46PM -0800, Russ Allbery wrote: Guillem Jover writes: Whether a package is being built within a chroot or not, has nothing to do with how that installation is being managed IMO. It feels a bit like recording what's the form factor of the machine being run on? :)

Re: Tainted builds (was Re: usrmerge -- plan B?)

Guillem Jover writes: > Whether a package is being built within a chroot or not, has nothing > to do with how that installation is being managed IMO. It feels a bit > like recording what's the form factor of the machine being run on? :) I think what people are trying to get at here is "was the

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, 2018-11-28 at 14:48:32 -0200, Antonio Terceiro wrote: > On Wed, Nov 28, 2018 at 02:57:52PM +0100, Guillem Jover wrote: > > This is actually a great idea! I went ahead and implemented this, see > > attached tentative patch which I'm planning on including in dpkg 1.19.3. > > Would you be

Re: usrmerge -- plan B?

On Fri, Nov 23, 2018 at 04:32:17PM +0100, Guillem Jover wrote: > Please, if we decide we want to do merged /usr, let's do it properly. I'm toying with the idea of creating a merged-usr package indicating 'this system has merged /usr'. It could either fail to install with an informational message

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Fri, 2018-11-30 at 05:51:35 +0900, Mike Hommey wrote: > "Only Essential: yes and direct build dependencies installed"? Why not > extend .buildinfo with the list of all packages installed that aren't > Essential:yes or build dependencies? Because that'd have the potential to leak privacy and

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Thu, Nov 29, 2018 at 09:07:46AM -0200, Antonio Terceiro wrote: > On Wed, Nov 28, 2018 at 07:02:07PM +0100, Bastian Blank wrote: > > On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > > > Would you be willing to also implement > > > Tainted-By: not-built-in-a-chroot > > > ? >

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, Nov 28, 2018 at 07:02:07PM +0100, Bastian Blank wrote: > On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > > Would you be willing to also implement > > Tainted-By: not-built-in-a-chroot > > ? > > What do you want to do with that? Even our own stuff not always uses >

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > Would you be willing to also implement > Tainted-By: not-built-in-a-chroot > ? What do you want to do with that? Even our own stuff not always uses chroot, why should it? Bastian -- Ahead warp factor one, Mr. Sulu.

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, Nov 28, 2018 at 06:40:46PM +0100, Guillem Jover wrote: > On Wed, 2018-11-28 at 22:13:41 +0500, Andrey Rahmatullin wrote: > > On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > > > (ischroot(1) is from debianutils which is Essential). > > > "On GNU/Linux, chroot detection

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, 2018-11-28 at 22:13:41 +0500, Andrey Rahmatullin wrote: > On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > > (ischroot(1) is from debianutils which is Essential). > "On GNU/Linux, chroot detection is not possible when not root." I think this was just missed as part of

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > Would you be willing to also implement > > Tainted-By: not-built-in-a-chroot That doesn't mean anything. You can build in a bad chroot and you can build in a clean minimal sid system which is not a chroot but a VM. >

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, Nov 28, 2018 at 02:57:52PM +0100, Guillem Jover wrote: > Hi! > > On Wed, 2018-11-28 at 07:52:08 +0500, Alexander E. Patrakov wrote: > > Well, the buildd configuration change has been reverted. What worries me now > > is that there is a risk not yet mitigated, coming from personal systems

Tainted builds (was Re: usrmerge -- plan B?)

Hi! On Wed, 2018-11-28 at 07:52:08 +0500, Alexander E. Patrakov wrote: > Well, the buildd configuration change has been reverted. What worries me now > is that there is a risk not yet mitigated, coming from personal systems of > Debian developers, and we should also check porter boxes. > > As

Re: Deployment of buildd machines [was: Re: usrmerge -- plan B?]

On 11/28/18 2:26 PM, Daniel Reichelt wrote: > On 11/22/18 1:56 PM, Ian Jackson wrote: >> (Bear in mind of course that happily our build machines >> *can* be reverted because they are frequently re-imaged.[…]) > > Using code from a debian package? Some script being hand-knitted using > hot

Deployment of buildd machines [was: Re: usrmerge -- plan B?]

On 11/22/18 1:56 PM, Ian Jackson wrote: > (Bear in mind of course that happily our build machines > *can* be reverted because they are frequently re-imaged.[…]) Using code from a debian package? Some script being hand-knitted using hot needles? Anyways, I'm interested in how this is done…"this"

Re: Re: usrmerge -- plan B?

On Wed, 2018-11-28 at 09:45 +, Holger Levsen wrote: > On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov > wrote: > As long as there is one Debian Developer (or any other person who has the > > right to upload binary packages) who has a merged /usr on his system used > > for

Re: Re: usrmerge -- plan B?

On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov wrote: > As long as there is one Debian Developer (or any other person who has the > right to upload binary packages) who has a merged /usr on his system used > for building packages, there is a risk of reintroducing the bug through

Re: Re: usrmerge -- plan B?

On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov wrote: As long as there is one Debian Developer (or any other person who has the > right to upload binary packages) who has a merged /usr on his system used > for building packages, there is a risk of reintroducing the bug through

Re: usrmerge -- plan B?

On Nov 28, "Alexander E. Patrakov" wrote: > Well, the buildd configuration change has been reverted. What worries me now > is that there is a risk not yet mitigated, coming from personal systems of > Debian developers, and we should also check porter boxes. This is not a new problem at all: in

Re: Re: usrmerge -- plan B?

Russ Allbery wrote: We had some things break because of a change to buildd configuration that caught some people by surprise. Well, the buildd configuration change has been reverted. What worries me now is that there is a risk not yet mitigated, coming from personal systems of Debian

Re: usrmerge -- plan B?

>> I think it would be good to hear from any derivatives in this >> position. We should probably ask them more formally than by having a >> horrible flamewar on -devel ... With my siduction dev hat on i want to have usrmerge as soon as possible. Built the last months with usrmerge activated and

Re: usrmerge -- plan B?

Ian Jackson wrote: > Unfortunately that means that while a properly planned and executed > transition to mandatory merged-/usr might well have offered overall > technical benefits for the Debian ecosystem, this is not now socially > possible and pressing on is not worth the social costs of being

Re: usrmerge -- plan B?

On Tue, Nov 27, 2018 at 12:57:38PM +, Ian Jackson wrote: > > In the case of unmerged /usr, the only benefits I'm aware of for the more > > complex case (unmerged /usr) are circular: existing Debian installations > > have it, so switching to merged /usr is a change; > I think this is true for

Re: usrmerge -- plan B?

Michael Stone writes: > On Tue, Nov 27, 2018 at 08:54:43AM +, Simon McVittie wrote: >> If I was wrong in assuming good faith and you were being argumentative >> for the sake of being argumentative, please stop: that is not >> constructive. >> >> Either way, please don't call me stupid. That

Re: usrmerge -- plan B?

On Tue, Nov 27, 2018 at 08:54:43AM +, Simon McVittie wrote: If I was wrong in assuming good faith and you were being argumentative for the sake of being argumentative, please stop: that is not constructive. Either way, please don't call me stupid. That is not *at all* constructive -

Re: usrmerge -- plan B?

On Tue, Nov 27, 2018 at 09:50:40AM +0100, Philip Hands wrote: Michael Stone writes: On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote: I disagree both that simple testing (that you could do with a KVM snapshot as well) would be hard and I disagree that the benefits of merged-/usr

Re: usrmerge -- plan B?

On Tue, 27 Nov 2018 09:50:40 +0100, Philip Hands wrote: >I have systems that were installed ages ago, which now have >insufficiently large root partitions. The usrmerge moves stuff from / to /usr, replacing /bin with a symlink to /usr/bin. This is likely to relax space constraints on small root

Re: usrmerge -- plan B?

Firstly, thanks for your measured and helpful contributions to this very unfortunate thread. Simon McVittie writes ("Re: usrmerge -- plan B?"): > I hope we can agree that unnecessary complexity is technical debt, but > necessary complexity is necessary: if complexity exi

Re: usrmerge -- plan B?

On 2018-11-27.08:54, Simon McVittie wrote: > On Tue, 27 Nov 2018 at 09:18:08 +0100, Stephan Seitz wrote: > > But I don’t want to get the /usr-merge forced upon my systems because this > > minority is obviously too stupid to install the package and migrate their > > systems on their own. > > That

Re: usrmerge -- plan B?

On Tue, 27 Nov 2018 at 09:18:08 +0100, Stephan Seitz wrote: > But I don’t want to get the /usr-merge forced upon my systems because this > minority is obviously too stupid to install the package and migrate their > systems on their own. That would be a terrible justification for merged /usr, but

Re: usrmerge -- plan B?

Michael Stone writes: > On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote: >>I disagree both that simple testing (that you could do with a KVM >>snapshot as well) would be hard and I disagree that the benefits of >>merged-/usr would be minor. > > Nobody has thus far pointed out a

Re: usrmerge -- plan B?

On 2018-11-27 08:18, Stephan Seitz wrote: But I don’t want to get the /usr-merge forced upon my systems because this minority is obviously too stupid to install the package and migrate their systems on their own. Please refrain from posting such messages; they are inappropriate and contribute

Re: usrmerge -- plan B?

On Mo, Nov 26, 2018 at 11:05:02 +0100, W. Martin Borgert wrote: I personally don't care about usrmerge, but if it is useful to a relevant minority, we should not reject it. Who says we should reject the usrmerge package? The minority who wishes for it can install it for years. But I don’t

Re: usrmerge -- plan B?

Quoting Ben Hutchings : Many of the rules in Debian policy are there to support a minority of users, but we try to follow them anyway. Hear, hear! I was about to write the same thing. I personally don't care about usrmerge, but if it is useful to a relevant minority, we should not reject it.

Re: usrmerge -- plan B?

On Mon, 2018-11-26 at 15:34 +0100, Stephan Seitz wrote: > On Mo, Nov 26, 2018 at 03:08:09 +0100, Marco d'Itri wrote: > > snapshot as well) would be hard and I disagree that the benefits of > > merged-/usr would be minor. > > There are no benefits of a merged /usr for users who don’t want to

Re: usrmerge -- plan B?

On Mon, 26 Nov 2018 at 15:00:41 +, Alastair McKinstry wrote: > Moving config from /etc to below /usr becomes useful for containers, and > hence clusters. Both that and merged /usr are particularly useful for containers and close-to-stateless embedded systems, but they are orthogonal. Please

Re: usrmerge -- plan B?

On Mon, 26 Nov 2018 17:12:34 +0100, Marco d'Itri wrote: >In other words, you are concerned about failure modes which have never >happened and that nobody has been able to explain how they may happen in >the future. s/you/customers looking for an excuse to ditch Debian/ Greetings Marc --

Re: usrmerge -- plan B?

On Mon, Nov 26, 2018 at 05:12:34PM +0100, Marco d'Itri wrote: > So far the worst case of "usrmerge failure" can be fixed by > deleting/moving some files (that were installed by you) and then running > the program again. There has never been any case which required > reinstalling/restoring a

Re: usrmerge -- plan B?

On Nov 26, Marc Haber wrote: > I would be willing to do this on production systems that can easily be > snapshotted and reverted in no time during an upgrade change, such as > VMs. Unless forced to, I'd rather not touch systems running on bare > metal and would need a restore-from-backup should

Re: usrmerge -- plan B?

On Mon, Nov 26, 2018 at 03:00:41PM +, Alastair McKinstry wrote: > > On 26/11/2018 14:44, Adam Borowski wrote: > > On Mon, Nov 26, 2018 at 09:29:50AM -0500, Michael Stone wrote: > > > On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote: > > > > I disagree both that simple testing

Re: usrmerge -- plan B?

On Mon, 26 Nov 2018 09:26:44 -0500, Michael Stone wrote: >On Mon, Nov 26, 2018 at 09:24:40AM +0100, Didier 'OdyX' Raboud wrote: >>usrmerge is in the archive for 3+ years now. What seems to be needed now is >>for a lot of us to actually _try_ it, find and report bugs, and get this >>through. >

Re: usrmerge -- plan B?

On 26/11/2018 14:44, Adam Borowski wrote: On Mon, Nov 26, 2018 at 09:29:50AM -0500, Michael Stone wrote: On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote: I disagree both that simple testing (that you could do with a KVM snapshot as well) would be hard and I disagree that the

Re: usrmerge -- plan B?

Russ Allbery writes ("Re: usrmerge -- plan B?"): > Ian Jackson writes: > > We can then have this discussion again early in the bullseye release > > cycle. If we must. > > That idea makes me wince. This will just result in the same thing > happening again. Let

Re: usrmerge -- plan B?

On Mon, Nov 26, 2018 at 09:29:50AM -0500, Michael Stone wrote: > On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote: > > I disagree both that simple testing (that you could do with a KVM > > snapshot as well) would be hard and I disagree that the benefits of > > merged-/usr would be

Re: usrmerge -- plan B?

On Mo, Nov 26, 2018 at 03:08:09 +0100, Marco d'Itri wrote: snapshot as well) would be hard and I disagree that the benefits of merged-/usr would be minor. There are no benefits of a merged /usr for users who don’t want to export /usr via NFS or want to use clusters/docker images/etc. And this

Re: usrmerge -- plan B?

On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote: I disagree both that simple testing (that you could do with a KVM snapshot as well) would be hard and I disagree that the benefits of merged-/usr would be minor. Nobody has thus far pointed out a single benefit to someone merging

Re: usrmerge -- plan B?

On Mon, Nov 26, 2018 at 09:24:40AM +0100, Didier 'OdyX' Raboud wrote: usrmerge is in the archive for 3+ years now. What seems to be needed now is for a lot of us to actually _try_ it, find and report bugs, and get this through. There's no way I'm running it on a production system. I would be

Re: usrmerge -- plan B?

On Nov 26, Ian Jackson wrote: > I could do it. But, frankly, this is quite a lot of work. I think > the work (throughout the Debian ecosystem) to test this properly far > outweighs the minor benefits. I disagree both that simple testing (that you could do with a KVM snapshot as well) would be

Re: usrmerge -- plan B?

On Nov 26, Bjørn Mork wrote: > "Migration is not (easily) reversible" was reported as important in > 2016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848626 This is not a bug: nothing is misbehaving, so classifying this as wishlist is correct. I even doubt that it would be technically

Re: usrmerge -- plan B?

Didier 'OdyX' Raboud writes ("Re: usrmerge -- plan B?"): > Of course you do have backups. For the sake of the argument, would you > consider trying an install of usrmerge on a restored backup VM somewhere? I could do it. But, frankly, this is quite a lot of work. I think the

Re: usrmerge -- plan B?

Marco d'Itri writes: > On Nov 26, Didier 'OdyX' Raboud wrote: > >> Sorry to be blunt about this, but have you reported these? Sniping at (any) > > No, they have not. There is a lot of handwaving in this thread but very > few results of actual tests. "Migration is not (easily) reversible" was

Re: usrmerge -- plan B?

On Nov 26, Didier 'OdyX' Raboud wrote: > Sorry to be blunt about this, but have you reported these? Sniping at (any) No, they have not. There is a lot of handwaving in this thread but very few results of actual tests. After creating again unmerged chroots for the buildds the only bugs left,

Re: usrmerge -- plan B?

On Mo, Nov 26, 2018 at 09:24:40 +0100, Didier 'OdyX' Raboud wrote: usrmerge is in the archive for 3+ years now. What seems to be needed now is for a lot of us to actually _try_ it, find and report bugs, and get this through. Why, if it was intended as an optional package for people who want

Re: usrmerge -- plan B?

Le jeudi, 22 novembre 2018, 14.56:10 h CET Ian Jackson a écrit : > There is tradeoff here between risk of breakage, and reduction of > future work (as most clearly explained by Russ). The argument that is > being made is that the risk is low because of a lack of reports of > breakage. > > Others

Re: usrmerge -- plan B?

Le jeudi, 22 novembre 2018, 00.17:54 h CET Michael Stone a écrit : > Then this needs to be a very explicit (and much better advertised) > decision, and it needs a much, much better implementation. You keep referring to usrmerge as buggy: > The current usrmerge package has no test mode, will bail

Re: usrmerge -- plan B?

On Thu, Nov 22, 2018 at 11:27:46AM -0800, Russ Allbery wrote: > > My position as a usrmerge sceptic, of letting them get on with doing > > their thing, now seems to have been unwise. The idea that it would be > > optional mutated, without proper discussion, and without a transition > > plan, into

Re: usrmerge -- plan B?

On Nov 24, "Gabriel F. T. Gomes" wrote: > Has this option been given enough attention? It sounds appealing in Yes. I would love to implement a --dry-run mode, but I still need to figure out how much complex it would be and if it could actually cover all cases. -- ciao, Marco signature.asc

Re: usrmerge -- plan B?

On 23 Nov 2018, Michael Stone wrote: >On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote: >>For these cases though maybe the usrmerge script could ask the admin >>on what to do to handle these particular binaries, instead of >>failing. > >Maybe, as I suggested upthread, there could

Re: usrmerge -- plan B?

On 11/24/18 8:51 PM, Alexander E. Patrakov wrote: Marco d'Itri wrote: On Nov 21, Michael Stone wrote: How many long-running production systems do you think people have run usrmerge on? I'd guess close to zero, since there is no advantage whatsoever Actually I have quite a lot personally,

Re: Re: usrmerge -- plan B?

Russ Allbery wrote: The reason why I personally jumped into this thread is that I don't think the initial fix proposed for R was good engineering. We should not be doing that sort of fragile machinations in Autoconf configuration. It will end in tears. We will miss some other binary later,

Re: Re: usrmerge -- plan B?

Marco d'Itri wrote: On Nov 21, Michael Stone wrote: How many long-running production systems do you think people have run usrmerge on? I'd guess close to zero, since there is no advantage whatsoever Actually I have quite a lot personally, with exactly zero problems. On some of them I also

Re: usrmerge -- plan B?

Hello Adam, On 23/11/2018 08:19, Adam Borowski wrote: > On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote: >> Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz >> : >>> >>> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote: If there are actual issues

Re: usrmerge -- plan B?

Hi! On Wed, 2018-11-21 at 10:23:46 +0100, Adam Borowski wrote: > with less confidence: > • making usrmerge Essential (large amount of effort, known issues) Oh dear, no, please! First off, as I've said in the past, I have no problem whatsoever with the concept, I think it brings both advantages

Re: usrmerge -- plan B?

On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote: > Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz > : > > > > On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote: > > >If there are actual issues encountered, we can always revert a change > > > > And how do you

Re: usrmerge -- plan B?

On Fr, Nov 23, 2018 at 03:14:44 +0100, Matthias Klumpp wrote: There are always unforseen issues to be expected when upgrading. And Of course, and since a dist-upgrade will bring newer software you may already have to fix configuration files. at the moment, the only issues that are known

Re: usrmerge -- plan B?

On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote: For these cases though maybe the usrmerge script could ask the admin on what to do to handle these particular binaries, instead of failing. Maybe, as I suggested upthread, there could be a preview mode in which the admin could

Re: usrmerge -- plan B?

On Fr, Nov 23, 2018 at 03:02:00 +0100, Hans wrote: Am Freitag, 23. November 2018, 14:47:28 CET schrieb Stephan Seitz: And how do you revert this change? As far as I have understand you can’t remove the usrmerge package and have your system in the old state again. Making an image of the whole

Re: usrmerge -- plan B?

Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz : > > On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote: > >If there are actual issues encountered, we can always revert a change > > And how do you revert this change? As far as I have understand you can’t > remove the usrmerge

Re: usrmerge -- plan B?

Am Freitag, 23. November 2018, 14:47:28 CET schrieb Stephan Seitz: > On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote: > And how do you revert this change? As far as I have understand you can’t > remove the usrmerge package and have your system in the old state again. Making an image

Re: usrmerge -- plan B?

On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote: If there are actual issues encountered, we can always revert a change And how do you revert this change? As far as I have understand you can’t remove the usrmerge package and have your system in the old state again. As others in

Re: usrmerge -- plan B?

Am Fr., 23. Nov. 2018 um 13:45 Uhr schrieb Ian Jackson : > Russ Allbery writes ("Re: usrmerge -- plan B?"): > > This is a much better summary of the thread, and I wish that you would > > have said this instead of claiming incorrectly that those same people are > >

Re: usrmerge -- plan B?

On Fri, 2018-11-23 at 12:45 +, Ian Jackson wrote: > Russ Allbery writes ("Re: usrmerge -- plan B?"): > > This is a much better summary of the thread, and I wish that you would > > have said this instead of claiming incorrectly that those same people are > > the o

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

Simon McVittie writes ("Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)"): > I'm not sure yet what the best plan for merged /usr is. I would definitely > like to make sure it's at least possible to continue to use merged > /usr

Re: usrmerge -- plan B?

Russ Allbery writes ("Re: usrmerge -- plan B?"): > This is a much better summary of the thread, and I wish that you would > have said this instead of claiming incorrectly that those same people are > the ones advocating for a full merge of all systems. Marco d'Itri writes (&quo

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

Quoting Holger Levsen : On Thu, Nov 22, 2018 at 10:11:24PM +0100, W. Martin Borgert wrote: Reminds me of the long /usr/doc -> /usr/share/doc transition in potato times. And we did not even have dh in those days. Sounds good to me! ITYM s#potato#slink, potato, woody, sarge, etch and lenny#

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

On Nov 22, Ansgar Burchardt wrote: > Well, the iptables case is different: those are compat symlinks created > by the package's maintainer scripts, not the /bin -> /usr/bin symlinks > that merged-/usr sets up. Actually iptables is different because it mixes (incorrectly) compatibility symlinks

  1   2   >