❦ 22 novembre 2018 18:00 +0100, Marco d'Itri :
> Actually I believe that the fact that this could be solved quickly and
> with a trivial change is a great argument in favour of the quality of my
> plan and work for switching to merged-/usr.
Thank you for that! My workstation was switched to
On Nov 22, Michael Stone wrote:
> Three years ago we were told this was to enable people to optionally do
> something, not that all users would be forced to migrate. That's a pretty
> substantial change.
At this point there is no plan to force anybody to migrate. It has just
been argued that it
On Nov 22, Russ Allbery wrote:
> I'm stating the advantages of fully converting Debian to merged /usr for
> engineering reasons: I don't think the existing optional migration is
> going to work very well or be supportable. On this point, I'm
> *disagreeing* with the usrmerge maintainer, who
On Nov 22, Matthew Vernon wrote:
> > In the worst case it will fail explaining that some local change (in
> > a directory which should not have been modified by the local admin, BTW)
> > needs to be addressed by the local admin and then it can be restarted
> > and continue its work.
> Could you
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#
(Started in 1999 and
Quoting Ansgar Burchardt :
This could also be seen as a slower path to merged-/usr: programs such
as `sed` would be in both /bin and /usr/bin and hard-coding either would
be fine (as with merged-/usr, but not without). Less static files would
be on a read-write root file system (if /usr is a
On Thu, 22 Nov 2018 at 21:08:14 +0100, Ansgar Burchardt wrote:
> If we want to support packages such as iptables moving binaries from
> /{s,}bin to /usr/{s,}bin
To be honest, I'm not sure whether we do want this. We should be careful,
at least.
Now that we don't support booting without /usr[1],
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Moving files around in such a matter that they are still available in
>> the old location (via a symlink) is not a very invasive change, so there
>> is only a small risk of problems.
>
> I think it's fair to note that our past experience in
Ian Jackson writes:
> It was very clear that what was proposed, some months ago, was
> *optional* usrmerge, which necessarily involves cross-compatibility. It
> was on that basis that there were few objections. Thus the original
> design promise from usrmerge proponents, when these changes
Russ Allbery writes ("Re: usrmerge -- plan B?"):
> Ian Jackson writes:
> >> "We ran into some unanticipated issues when we usrmerged our build
> >> systems, and we think the way to fix that is to force merge every one
> >> of our users' syste
Marco d'Itri writes:
> In the worst case it will fail explaining that some local change (in
> a directory which should not have been modified by the local admin, BTW)
> needs to be addressed by the local admin and then it can be restarted
> and continue its work.
Could you expand on this? I'm
On Thu, Nov 22, 2018 at 06:00:45PM +0100, Marco d'Itri wrote:
You should have asked for an explicit plan three years ago when I first
announced that I was working on this. At this point you are just
creating arbitrary requirements that would delay forever this change.
Three years ago we were
On Nov 22, Michael Stone wrote:
> That's not actually what happens: the files are still available in the old
> location *if and only if the process is fully successful*. If there are any
> issues you have a partially migrated system in which the files are *not*
> still available in the old
On Nov 22, Ian Jackson wrote:
> I would also like to point out that change planning is the job of
> someone who wants to change something. That includes not only:
I planned for everything that I could foresee.
I did not think about the buildds issue, but this is hardly the first
time that some
On Thu, Nov 22, 2018 at 05:15:53PM +0100, Ansgar Burchardt wrote:
Moving files around in such a matter that they are still available in
the old location (via a symlink) is not a very invasive change, so
there is only a small risk of problems. That matches what was reported
so far.
That's not
Ansgar Burchardt writes:
> Moving files around in such a matter that they are still available in
> the old location (via a symlink) is not a very invasive change, so there
> is only a small risk of problems.
I think it's fair to note that our past experience in Debian doesn't
really support
On Thu, 2018-11-22 at 13:56 +, Ian Jackson wrote:
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > On Nov 22, Ian Jackson wrote:
> > > Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > > > So far nobody reported anything signi
Ian Jackson writes:
> Michael Stone writes ("Re: usrmerge -- plan B?"):
>> Let's restate this so it can stand clearly on its own:
>> "We ran into some unanticipated issues when we usrmerged our build
>> systems, and we think the way to fix that is to f
Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> On Nov 22, Ian Jackson wrote:
> > Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > > So far nobody reported anything significant.
> >
> > I hear there was a major free software project
On Nov 22, Ian Jackson wrote:
> I hear there was a major free software project who accidentally
> usrmerged their build systems and discovered that they then built
> broken packgaes.
And it was quickly fixed, so no big deal.
--
ciao,
Marco
signature.asc
Description: PGP signature
Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> So far nobody reported anything significant.
I hear there was a major free software project who accidentally
usrmerged their build systems and discovered that they then built
broken packgaes.
Ian.
--
Ian JacksonThese opinio
On Nov 22, Michael Stone wrote:
> Again, how many weren't systems you're responsible for? I have no doubt that
> you took care of the problems that you encountered personally when you wrote
> the tool. I've seen a lot of problems on systems in the wild that don't
No: what I meant is that I did
Michael Stone writes ("Re: usrmerge -- plan B?"):
> Let's restate this so it can stand clearly on its own:
>
> "We ran into some unanticipated issues when we usrmerged our build
> systems, and we think the way to fix that is to force merge every one of
> our us
On Thu, Nov 22, 2018 at 12:32:14PM +0100, Marco d'Itri wrote:
I use merged-/usr without any issues on many stable systems, both new
and upgraded.
Again, how many weren't systems you're responsible for? I have no doubt
that you took care of the problems that you encountered personally when
Andreas Henriksson writes ("Re: usrmerge -- plan B?"):
> Here's a dumbed down narrative for you:
Svante's message was pretty bad but yours is even worse.
Would everyone please stop it.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an addre
Michael Stone writes ("Re: usrmerge -- plan B?"):
> No way we can hit that date with a forced merge. Where are the testing
> reports showing that this actually works on a broad range of systems?
> And now we're getting into the winter holiday season? Pushing that now
> w
On Nov 22, Jonathan Dowland wrote:
> Long-running production systems would presumably be running Stable. We
> need testing or unstable systems to try usrmerge. I don't think even
> reporting on the success of usrmerge on current-Stable¹ would be
> necessarily useful.
I use merged-/usr without
On Thu, Nov 22, 2018 at 12:54:45AM +0100, Svante Signell wrote:
Unfortunately Simon writes too long mails. Who can even thake the time
to read all these verbalism. Things could be written more condensed.
Please, can somebody summarize his verbosity! Maybe he is a politcian?
I don't think this
On Wed, Nov 21, 2018 at 04:21:42PM -0500, 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 to doing so. I'd also expect those to be the systems most
likely to have issues.
Svante Signell writes:
...
> Who can even thake the time to read all these verbalism.
This is a criticism of an attempt to educate, made from a position of
ignorance. I don't think we need we need this on our mailing lists.
> Things could be written more condensed.
Given that Simon was
On Thu, Nov 22, 2018 at 12:54:45AM +0100, Svante Signell wrote:
> Unfortunately Simon writes too long mails. Who can even thake the time to read
> all these verbalism. Things could be written more condensed. Please, can
> somebody summarize his verbosity! Maybe he is a politcian?
Here's a dumbed
On Wed, 2018-11-21 at 14:43 +, Holger Levsen wrote:
> Hi Simon,
>
> On Wed, Nov 21, 2018 at 02:05:42PM +, Simon McVittie wrote:
> [...]
> > > Another question is, why?
>
> [...]
>
> thank you very much for explaining in detail why usrmerge is sensible
> and the right thing to do for
On 2018-11-22 00:33:25 +0100 (+0100), Svante Signell wrote:
> On Wed, 2018-11-21 at 13:09 +0100, Marc Haber wrote:
> > On Wed, 21 Nov 2018 10:52:22 +0100, Adam Borowski
> > wrote:
> > > I am seriously claiming that RHEL is in the place Solaris was
> > > in 2010. Rapidly falling user share (like
On Wed, 2018-11-21 at 13:09 +0100, Marc Haber wrote:
> On Wed, 21 Nov 2018 10:52:22 +0100, Adam Borowski
> wrote:
> > I am seriously claiming that RHEL is in the place Solaris was in 2010.
> > Rapidly falling user share (like Solaris, it was ubiquitous in the past!),
> > acquired by a company
On Wed, Nov 21, 2018 at 02:55:56PM -0800, Russ Allbery wrote:
I don't believe supporting legacy installs *without doing the migration*
is an option, or at least an option that we should take. We could
theoretically make it work, but the ongoing burden to packagers and to
our testing
Michael Stone writes:
> On Wed, Nov 21, 2018 at 02:19:56PM -0800, Russ Allbery wrote:
>> Doing this check in reproducible-builds definitely helps allievate my
>> concerns as a backstop, but this is still fragile and we don't have a
>> tight test/fix cycle. And, in general, I'm dubious of a path
On Wed, Nov 21, 2018 at 02:19:56PM -0800, Russ Allbery wrote:
Doing this check in reproducible-builds definitely helps allievate my
concerns as a backstop, but this is still fragile and we don't have a
tight test/fix cycle. And, in general, I'm dubious of a path where we
support building a
Matthias Klumpp writes:
> (At the moment I don't actually see the upcoming doom - a few packages
> broke, bugs were fixed, life goes on. If it turns out that we are not
> able to cope with new bugs in time, we can always change decisions
> later).
The reason why I personally jumped into this
Am Mi., 21. Nov. 2018 um 22:51 Uhr schrieb Marco d'Itri :
>
> 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
Holger Levsen writes:
> On Wed, Nov 21, 2018 at 12:38:53PM -0800, Russ Allbery wrote:
>> But it's not just my opinion that matters. I think we need to decide
>> this somehow as a project, whether via the TC or via GR or something,
>> because there's a real disagreement here over whether we can
Michael Stone writes:
> 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 to doing so. I'd also expect those to be the systems most
> likely to have issues.
Yup, lack of testing is definitely a
On Wed, Nov 21, 2018 at 10:49:54PM +0100, 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
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 enjoy advantages of
On Wed, Nov 21, 2018 at 09:28:11PM +, Holger Levsen wrote:
Or what am I missing?
The possibility that your system will break? The current usrmerge
package has no test mode, will bail with a partially-converted system if
it runs into problems, and has no way to revert the process. A
On Wed, Nov 21, 2018 at 12:38:53PM -0800, Russ Allbery wrote:
> But it's not just my opinion that matters. I think we need to decide this
> somehow as a project, whether via the TC or via GR or something, because
> there's a real disagreement here over whether we can or should
> force-upgrade all
On Wed, Nov 21, 2018 at 03:45:35PM -0500, Jeremy Bicha wrote:
On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote:
But it's not just my opinion that matters. I think we need to decide this
somehow as a project, whether via the TC or via GR or something, because
there's a real disagreement here
On Wed, Nov 21, 2018 at 12:49:04PM -0800, Russ Allbery wrote:
This seems like too high of a level of pessimism given that the usrmerge
package already implements this sort of force-merge and some people have
it installed and don't seem to be running into a bunch of bugs. The last
round of
On Mi, Nov 21, 2018 at 01:09:47 +0100, Marc Haber wrote:
Debian, is, btw, also losing quickly for not keeping pace with the
world around it.
Or maybe it scares people away with its bullshit decisions.
Stephan
--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
smime.p7s
Jeremy Bicha writes:
> On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote:
>> But it's not just my opinion that matters. I think we need to decide
>> this somehow as a project, whether via the TC or via GR or something,
>> because there's a real disagreement here over whether we can or should
Michael Stone writes:
> On Wed, Nov 21, 2018 at 09:59:24AM -0800, Russ Allbery wrote:
>> If we just force-merge every system on upgrade, none of those
>> inconsistencies matter, and I do believe we could successfully complete
>> that process (with some bumps, of course).
> I think that's likely
On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote:
> But it's not just my opinion that matters. I think we need to decide this
> somehow as a project, whether via the TC or via GR or something, because
> there's a real disagreement here over whether we can or should
> force-upgrade all Debian
Marco d'Itri writes:
> On Nov 21, Russ Allbery wrote:
>> I think there are some arguments to be made for just force-merging and
>> moving on, but they're mostly "tidiness" arguments (letting everyone
> No, they are not that at all. I have never argued about "tidiness", nor
> did anybody else
On Nov 21, Russ Allbery wrote:
> I think there are some arguments to be made for just force-merging and
> moving on, but they're mostly "tidiness" arguments (letting everyone
No, they are not that at all. I have never argued about "tidiness", nor
did anybody else that is working to support
On Wed, Nov 21, 2018 at 09:59:24AM -0800, Russ Allbery wrote:
If we just force-merge every system on upgrade, none of those
inconsistencies matter, and I do believe we could successfully complete
that process (with some bumps, of course).
I think that's likely to be the most painful upgrade
Adam Borowski writes:
> Thus, either usrmerge Essential or not included in Buster -- no middle
> way.
I think I agree with this.
My impression is that most of the problems with usrmerge are because we're
trying to support a halfway position that Red Hat did not try to support,
where some
Am Mittwoch, 21. November 2018, 11:34:47 CET schrieb Adam Borowski:
Thanks Adam for the fast response.
I am looking forward to usrmerge, as I see only advantages at the moment.
Best
Hans
> On Wed, Nov 21, 2018 at 10:39:38AM +0100, Hans wrote:
> > However, this did not answer my question, so I
Hi Simon,
On Wed, Nov 21, 2018 at 02:05:42PM +, Simon McVittie wrote:
[...]
> > Another question is, why?
[...]
thank you very much for explaining in detail why usrmerge is sensible
and the right thing to do for Debian, the universal OS.
I'll link your mail on wiki.debian.org/UsrMerge now
On Tue, 20 Nov 2018 at 22:16:17 +0100, Adam Borowski wrote:
> There's been another large bout of usrmerge issues recently
These are one example of a wider class of issues, which Debian is going
to keep running into, and solving, as long as we're a binary distribution
(as opposed to a source
On Wed, 21 Nov 2018 11:57:14 +, Ian Jackson
wrote:
>I suspect you meant to refer to this:
> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
>
>
>2. Solaris compatibility
>
>Well, this is a real argument. But, seriously, do we care ?
I find it very interesting to
On Wed, 21 Nov 2018 10:52:22 +0100, Adam Borowski
wrote:
>I am seriously claiming that RHEL is in the place Solaris was in 2010.
>Rapidly falling user share (like Solaris, it was ubiquitous in the past!),
>acquired by a company known for wringing dry a small number of lucratious
>customers --
On Wed, Nov 21, 2018 at 11:31:40AM +, Jonathan Dowland wrote:
I'll upgrade to 7.6 and see what happens.
I've upgraded and /bin -> /usr/bin
However I didn't correctly check this before so it might have already
happened.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄
Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> On Nov 20, Adam Borowski wrote:
> > Another question is, why?
>
> It has been documented here long ago: https://wiki.debian.org/UsrMerge .
I looked at that page and it has no rationale.
> You are misconstruc
Hi,
Adam Borowski writes:
FTR, I agree with the broad thrust of your mail; I'm not sure I've seen
a convincing case for /usr-merge yet.
> I am seriously claiming that RHEL is in the place Solaris was in 2010.
But I want to take issue with this. RHEL is moderately-widely used,
because if you
On Wed, Nov 21, 2018 at 11:02:44AM +0100, Marc Haber wrote:
Did RHEL do that from 7.x to 7.x+1 (where updates are supported)? Or
from x.y to z.0 where ther recommended migration way is a reinstall?
I don't know the answer to when or how this happens, but my local RHEL
VM is on 7.5 and doesn't
Am Mittwoch, 21. November 2018, 11:34:47 CET schrieb Adam Borowski:
Thanks Adam for the fast response.
I am looking forward to usrmerge, as I see only advantages at the moment.
Best
Hans
> On Wed, Nov 21, 2018 at 10:39:38AM +0100, Hans wrote:
> > However, this did not answer my question, so I
On Wed, Nov 21, 2018 at 10:39:38AM +0100, Hans wrote:
> However, this did not answer my question, so I like to aksk here:
>
> Will usrmerge break my system?
>
> I have /usr on a seperate partition and I have it encrypted with luks.
> Of course I am running a standard kernwel with initrd.
No
Hi folks,
I am following this thread qwith great interest. And I also read about
usrmerge, too.
However, this did not answer my question, so I like to aksk here:
Will usrmerge break my system?
I have /usr on a seperate partition and I have it encrypted with luks.
Of course I am running a
On Wed, 21 Nov 2018 08:56:58 +0100, Marco d'Itri wrote:
>it's RHEL that matters and it switched to
>a merged-/usr
Did RHEL do that from 7.x to 7.x+1 (where updates are supported)? Or
from x.y to z.0 where ther recommended migration way is a reinstall?
Greetings
Marc
--
On Wed, Nov 21, 2018 at 08:56:58AM +0100, Marco d'Itri wrote:
> On Nov 20, Adam Borowski wrote:
>
> If you are seriously concerned with the small issuses caused by the
> transition to merged-/usr then I have a better proposal.
> Plan C: just stop supporting non-merged-/usr systems since these
On Wed, Nov 21, 2018 at 06:37:11AM +, Domenico Andreoli wrote:
> On November 20, 2018 9:16:17 PM UTC, 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?
>
> My preferred plan
On Nov 20, Adam Borowski wrote:
If you are seriously concerned with the small issuses caused by the
transition to merged-/usr then I have a better proposal.
Plan C: just stop supporting non-merged-/usr systems since these
problems are caused by having to support both, and there is no real
On November 20, 2018 9:16:17 PM UTC, Adam Borowski wrote:
>Hi!
Hi,
>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?
My preferred plan B is the one allowing to release Buster on time with most
Hi!
There's been another large bout of usrmerge issues recently, and a bunch of
new problems have been identified. The point of the whole idea has been
questioned, as well.
Thus, I'd propose holding our horses and thinking a bit. I'd also like to
suggest an alternate approach:
* let's scrap
101 - 173 of 173 matches
Mail list logo
