On 3 January 2016 at 03:52, ChangZhuo Chen (陳昌倬) wrote:
> On Sun, Jan 03, 2016 at 01:23:14AM -0200, Martinx - ジェームズ wrote:
>> It violates the FHS 2.3 standards.
>>
>> http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html
>
> Can you cite the requirement in FHS 2.3 which is violated by usrmerge.
Martinx - ジェームズ writes:
> Just tell the users that "/usr" isn't supported on a separated
> partition anymore (tell users what will happen if they do this /
> limitations), and do not touch anything else. During install, while
> partitioning storage, print a message about this, if user tries to
> s
Daniel Reurich writes:
...
> Because systemd doesn't work without /usr on the root partition isn't a
> good reason either.
You are right ... it is a poor reason, because it is pure fantasy.
> That just means systemd is broken by design and needs to be fixed.
If what you claimed were true, then
On 03/01/16 22:33, Philip Hands wrote:
> Daniel Reurich writes:
>
> ...
>> Because systemd doesn't work without /usr on the root partition isn't a
>> good reason either.
>
> You are right ... it is a poor reason, because it is pure fantasy.
Then why is it that since the introduction of systemd
On Sun, Jan 03, 2016 at 11:04:20PM +1300, Daniel Reurich wrote:
> >> Because systemd doesn't work without /usr on the root partition isn't a
> >> good reason either.
> >
> > You are right ... it is a poor reason, because it is pure fantasy.
>
> Then why is it that since the introduction of system
On Sun, 2016-01-03 at 23:04 +1300, Daniel Reurich wrote:
> On 03/01/16 22:33, Philip Hands wrote:
> > Daniel Reurich writes:
> >
> > ...
> > > Because systemd doesn't work without /usr on the root partition isn't a
> > > good reason either.
> >
> > You are right ... it is a poor reason, because
On Sun, 03 Jan 2016 23:04:20 +1300, Daniel Reurich
wrote:
>On 03/01/16 22:33, Philip Hands wrote:
>> Daniel Reurich writes:
>>
>> ...
>>> Because systemd doesn't work without /usr on the root partition isn't a
>>> good reason either.
>>
>> You are right ... it is a poor reason, because it is pu
What is the "upgrade path" for an older system that has /usr split
off? Will it just stop being bootable after upgrading?
It just needs to use an initramfs.
A standalone /usr without an initramfs IS ALREADY NOT SUPPORTED by
systemd.
This is not relevant for merged /usr.
What is the "upgrade pa
On Sun, Jan 03, 2016 at 11:40:34AM +0100, Eric Valette wrote:
> The debian installer should first loudly warn that having a separated / and
> /usr may break things in the future
ITYM "already breaks things"
--
WBR, wRAR
signature.asc
Description: PGP signature
On 03/01/16 23:18, Ben Hutchings wrote:
>> Then why is it that since the introduction of systemd is having /usr on
>> a separate partition suddenly considered evil and systemd complains
>> loudly about it. It always has worked and does work fine for me with
>> sysvinit
>
> systemd complains if i
On Jan 03, Eric Valette wrote:
> The debian installer should first loudly warn that having a separated / and
> /usr may break things in the future but not forbid it. With that in place,
This is not true: you just need to use an initramfs.
"I have always done this in a different way" is not a vali
❦ 4 janvier 2016 00:03 +1300, Daniel Reurich :
>>> Then why is it that since the introduction of systemd is having /usr on
>>> a separate partition suddenly considered evil and systemd complains
>>> loudly about it. It always has worked and does work fine for me with
>>> sysvinit
>>
>> system
On 04/01/16 00:25, Marco d'Itri wrote:
> On Jan 03, Eric Valette wrote:
>
>> The debian installer should first loudly warn that having a separated / and
>> /usr may break things in the future but not forbid it. With that in place,
> This is not true: you just need to use an initramfs.
> "I have a
The debian installer should first loudly warn that having a separated / and
/usr may break things in the future but not forbid it. With that in place,
This is not true: you just need to use an initramfs.
Ok, so it should warn that this setup will soon require to use an
initramfs. I just pointe
On Sat, Jan 2, 2016 at 6:42 PM, Geert Stappers wrote:
> On Fri, Jan 01, 2016 at 03:53:03PM +0100, Marco d'Itri wrote:
>> On Jan 01, Ian Jackson wrote:
>> With a merged /usr you would be able to serve the whole OS over NFS (and
>> even share it among multiple systems without the constant threat o
On Sun, Jan 3, 2016 at 11:04 AM, Daniel Reurich wrote:
> On 03/01/16 22:33, Philip Hands wrote:
>> Daniel Reurich writes:
>>> Because systemd doesn't work without /usr on the root partition isn't a
>>> good reason either.
>>
>> You are right ... it is a poor reason, because it is pure fantasy.
On Jan 03, Eric Valette wrote:
> >This is not true: you just need to use an initramfs.
> Ok, so it should warn that this setup will soon require to use an initramfs.
It is the Debian default, there is no need to do this.
> Same for your proposal : nothing really sound except systemd wants it...
Hi,
On 03.01.2016 12:25, Marco d'Itri wrote:
> "I have always done this in a different way" is not a valid use case,
> sorry.
"Compatibility" is a very valid use case. Debian is famous for backwards
compatibility and trouble-free upgrades.
I can certainly see the allure of a tightly integrated
Hallo,
* Michael Biebl [Sun, Jan 03 2016, 03:22:03AM]:
> Am 02.01.2016 um 22:08 schrieb Marc Haber:
> > On Sat, 2 Jan 2016 18:42:14 +0100, Geert Stappers
> > wrote:
> >> To me is this "TheUsrMerge" something like among
> >> * "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck"
>
Eduard Bloch, on Sun 03 Jan 2016 14:06:22 +0100, wrote:
> OTOH UsrMerge breaks some habits, i.e. going to /share/doc/foo feels
UsrMerge proposed by Marco is the converse.
It is *not* putting a /usr -> / symlink.
Samuel
Hallo,
* Daniel Reurich [Mon, Jan 04 2016, 12:46:46AM]:
> On 04/01/16 00:25, Marco d'Itri wrote:
> > On Jan 03, Eric Valette wrote:
> >
> >> The debian installer should first loudly warn that having a separated / and
> >> /usr may break things in the future but not forbid it. With that in place,
Hallo,
* Samuel Thibault [Sun, Jan 03 2016, 02:15:31PM]:
> Eduard Bloch, on Sun 03 Jan 2016 14:06:22 +0100, wrote:
> > OTOH UsrMerge breaks some habits, i.e. going to /share/doc/foo feels
>
> UsrMerge proposed by Marco is the converse.
>
> It is *not* putting a /usr -> / symlink.
I didn't say or
Package: wnpp
Severity: wishlist
Owner: Timo Jyrinki
* Package name: foma
Version : 0.9.18
Upstream Author : Mans Hulden
* URL : https://bitbucket.org/mhulden/foma/
http://code.google.com/p/foma/
* License : GPL
Programming Lang: C
Desc
Hi,
This message was not intended to be sent to a debian-* mailing list by
the author. However, since it is (in my opinion) of large interest I
got the permission to forward it to debian-devel. Hopefully, also some
of the debian-devel subscribers will appreciate it too.
Thanks!
Forwarde
On 2016-01-03 15:59:37, Svante Signell wrote:
> Hi,
>
> This message was not intended to be sent to a debian-* mailing list by
> the author. However, since it is (in my opinion) of large interest I
> got the permission to forward it to debian-devel. Hopefully, also some
> of the debian-devel subs
Hello Marco d'Itri.
On Thu, Dec 31, 2015 at 01:51:45AM +0100, Marco d'Itri wrote:
> We have a reasonably tested usrmerge package which can be used to
[...]
> I welcome your comments, but if you have any questions then please read
> the FAQ first:
> https://wiki.debian.org/UsrMerge
> https://anon
Marc Haber wrote:
> See the discussion about EnvironmentFile which "should never have been
> implemented" and "should be removed" on systemd-devel which resulted
> in one side of the discussion being put on moderation (guess which one
> got silenced).
The ones posting messages like
http://lists.fr
On 03/01/16 13:23, Eduard Bloch wrote:
> I didn't say or assume that. It doesn't matter how you see it, in the
> end all /usr/*foo* would be come /*foo*, sooner or later.
Not in the UsrMerge design. Because UsrMerge deprecates
/{bin,lib,sbin...} and treats /usr/* as the canonical location for thos
On 2016-01-03 17:03:02, Simon McVittie wrote:
> […] For
> instance, /bin -> /usr/bin is needed because otherwise #!/bin/sh would
> stop working, […]
This brings to mind—I wonder if the performance impact of having /bin/sh
be read through two indirections (/bin/sh → /usr/bin/sh →
/usr/bin/{dash, ba
Hi,
On Sun, Jan 03, 2016 at 04:08:53PM +0100, Iustin Pop wrote:
> On 2016-01-03 15:59:37, Svante Signell wrote:
> > Hi,
> >
> > This message was not intended to be sent to a debian-* mailing list by
> > the author. However, since it is (in my opinion) of large interest I
> > got the permission to
On 2016-01-03 12:59:01, Tom H wrote:
> On Sat, Jan 2, 2016 at 6:42 PM, Geert Stappers wrote:
> I don't like usr-merge because it goes against my historical
> expectation that "/{,s}bin" be separate from their /usr namesakes and
> contain binaries required for boot.
OK, so adjust your historical e
On Sun, Jan 03, 2016 at 03:59:37PM +0100, Svante Signell wrote:
> This message was not intended to be sent to a debian-* mailing list by
> the author. However, since it is (in my opinion) of large interest I
> got the permission to forward it to debian-devel. Hopefully, also some
> of the debian-de
Daniel Reurich writes:
> Ah, so it's actually packages that don't separate device configuration
> logic from the application or daemons properly that has caused the
> brokenness. Can we identify and fix the packages that cause this issue?
No. Debian has basically given up on this; there are wa
On Jan 03, Simon Richter wrote:
> > "I have always done this in a different way" is not a valid use case,
> > sorry.
> "Compatibility" is a very valid use case. Debian is famous for backwards
> compatibility and trouble-free upgrades.
Requiring to use an initramfs in some configurations does not
On Jan 03, Andreas Henriksson wrote:
> First, it would be nice to have a preinst check if the system has any
> running services that uses ProtectSystem and offer a choice to stop
> (and restart) them in case having them running is really a problem...
I will think about this, I need to check how m
Hi Marco,
On 03-01-16 19:43, Marco d'Itri wrote:
> Also, I am not really up to date on the modern debconf best practices:
> can somebody recommend a package that I can use foor an example of
> a debconf question that can abort the package installation?
Not sure if it is really what you are look
On Sun, 3 Jan 2016 13:44:36 +0100, Simon Richter
wrote:
>"Compatibility" is a very valid use case. Debian is famous for backwards
>compatibility and trouble-free upgrades.
We have been able to do this in the past, yes.
I doubt we will be able to keep this promise in the future.
But I have been
On Sun, 3 Jan 2016 16:08:53 +0100, Iustin Pop
wrote:
>Wow, here I was thinking this would be some informed oppinion, but:
>
>"Oh, there are tools with which you can periscope into
>initramfs, but have you ever really looked at everything in an
>initramfs."
>
>Wait, what? Yes, I have many times unp
Hi,
On 03.01.2016 19:15, Marco d'Itri wrote:
>> However, this also means that systemd can never fully replace sysvinit,
>> except on desktops, laptops and servers that follow a standard layout.
> I see no reason why this would be true.
Because the alternative is to bloat the scope of the system
>This is not true: you just need to use an initramfs.
Ok, so it should warn that this setup will soon require to use an initramfs.
It is the Debian default, there is no need to do this.
Being debian installer default does not mean any debian users
1) really has any benefit of using it a
On 01/03/2016 12:03 PM, Daniel Reurich wrote:
> On 03/01/16 23:18, Ben Hutchings wrote:
>
>>> Then why is it that since the introduction of systemd is having /usr on
>>> a separate partition suddenly considered evil and systemd complains
>>> loudly about it. It always has worked and does work fin
Note that mounting /usr early, something we *already do*, is separate from
actually merging /usr with /bin and /lib. Once you mount /usr early, it's
rather less important whether you actually merge the file systems. While
it does let you do some interesting things, I see it as more of a cleanup.
Eric Valette writes:
> But could you elaborate a bit on "mounting /usr early, something we
> *already do*" if you do not implicitly refer to initramfs solution.
There are other people who know a lot more about the machinery here than I
do, but my understanding is that we currently use a variety
On Sun, Jan 03, 2016 at 10:14:14AM -0800, Russ Allbery wrote:
> Daniel Reurich writes:
>
> > Ah, so it's actually packages that don't separate device configuration
> > logic from the application or daemons properly that has caused the
> > brokenness. Can we identify and fix the packages that cau
On Sun, Jan 3, 2016 at 6:17 PM, Iustin Pop wrote:
> On 2016-01-03 12:59:01, Tom H wrote:
>>
>> I don't like usr-merge because it goes against my historical
>> expectation that "/{,s}bin" be separate from their /usr namesakes and
>> contain binaries required for boot.
>
> OK, so adjust your histori
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/03/2016 07:15 PM, Marco d'Itri wrote:
> On Jan 03, Simon Richter wrote:
>
>>> "I have always done this in a different way" is not a valid use
>>> case, sorry.
>> "Compatibility" is a very valid use case. Debian is famous for
>> backwards co
We may never know what Ian the man actually wrote, or what
sort of influence he was under when he wrote it.
The only way we begin to know is if Ian's family, the executor
of his estate, the police, and administrators of Twitter come
forward and tell the story of what they have observed.
One mig
Florian Lohoff writes:
> On Sun, Jan 03, 2016 at 10:14:14AM -0800, Russ Allbery wrote:
>> No. Debian has basically given up on this; there are way too many
>> packages and way too much stuff that would have to be moved to /bin and
>> /lib in order to preserve the traditional semantics that allow
On 03/01/2016 22:10, Russ Allbery wrote:
Eric Valette writes:
The problem of getting /usr mounted before things start using it is mostly
separate from the question of whether we want to merge it with /bin and
/lib. This thread is more about the latter than the former. (Obviously,
mounting
On 2016-01-03 22:22:16, Tom H wrote:
> On Sun, Jan 3, 2016 at 6:17 PM, Iustin Pop wrote:
> > On 2016-01-03 12:59:01, Tom H wrote:
> >>
> >> I don't like usr-merge because it goes against my historical
> >> expectation that "/{,s}bin" be separate from their /usr namesakes and
> >> contain binaries
On Sun, Jan 3, 2016, at 16:43, Marco d'Itri wrote:
> I just have not found yet how to determine if the system was booted
> using an initramfs or not. Does anybody have any hint?
I don't think there is any source for that information that one can
really trust ATM, AFAIK.
We could add it in usersp
Eric Valette writes:
> If it is just to close once for all the right location philosophical
> debate, I would say it will be over priced: changing executable PATH
> will just breaks million scripts people have written themselves on top
> of original debian install to maintain their system or do w
❦ 3 janvier 2016 22:30 +0100, Eric Valette :
>> The problem of getting /usr mounted before things start using it is mostly
>> separate from the question of whether we want to merge it with /bin and
>> /lib. This thread is more about the latter than the former. (Obviously,
>> mounting /usr ear
On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
> Well, just for the heck of it I wrote a braindead-simple initrd
> implementation in just 300 LOC:
>
> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae
Oho! Cool!
> My question would be: would those people here who have separate /usr
On 01/03/2016 10:53 PM, Henrique de Moraes Holschuh wrote:
> On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
>> My question would be: would those people here who have separate /usr
>> and aren't using initrd be willing to put up with something like that?
>
> I don't know if they will, but t
On Sun, Jan 3, 2016, at 19:59, Christian Seiler wrote:
> On 01/03/2016 10:53 PM, Henrique de Moraes Holschuh wrote:
> > On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
> >> My question would be: would those people here who have separate /usr
> >> and aren't using initrd be willing to put up
On 01/03/2016 11:06 PM, Henrique de Moraes Holschuh wrote:
> On Sun, Jan 3, 2016, at 19:59, Christian Seiler wrote:
>> On 01/03/2016 10:53 PM, Henrique de Moraes Holschuh wrote:
>>> On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
My question would be: would those people here who have se
On 01/02/2016 06:42 PM, Geert Stappers wrote:
> To me is this "TheUsrMerge" something like among
> * "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck"
> * "there was a question about /bin/kill and /usr/bin/killall being
> inconsequent"
> * "we could not agree if p{erl,ython,hp
On Sun, 2016-01-03 at 21:34 +0100, Eric Valette wrote:
> > > > This is not true: you just need to use an initramfs.
> > > Ok, so it should warn that this setup will soon require to use an
> > > initramfs.
> > It is the Debian default, there is no need to do this.
>
> Being debian installer defaul
On Sun, 2016-01-03 at 21:21 +0100, Simon Richter wrote:
> Hi,
>
> On 03.01.2016 19:15, Marco d'Itri wrote:
[...]
> > Anyway, if you think that the merged /usr scheme is about systemd then
> > you are automatically disqualified from taking part in this discussion
> > because you are not understan
Hi,
On 03.01.2016 23:32, Ben Hutchings wrote:
> An initramfs is mandatory if using the standard kernel packages, as I
> think most people do.
Not on embedded systems. While we do have the advantage there that the
people putting the system together are generally clueful, it should
still remain po
On Sun, 2016-01-03 at 13:10 -0800, Russ Allbery wrote:
> Eric Valette writes:
>
> > But could you elaborate a bit on "mounting /usr early, something we
> > *already do*" if you do not implicitly refer to initramfs solution.
>
> There are other people who know a lot more about the machinery here
On 01/03/2016 04:23 AM, Martinx - ジェームズ wrote:
> This "UseMerge" just brings more insanity into Debian. What is wrong
> with you guys?! For God's sake...
Even if you disagree with something, please don't call it insanity.
> It violates the FHS 2.3 standards.
Sure, if you mean the sentence that "
I'm confused why you think anything will break. There would obviously be
symlinks, so anything that's currently in /bin will continue to work if
invoked with an absolute /bin path.
I consider linking across file system a very bad practice because if
/usr gets errors all the symlinks may be bro
On Sun, 2016-01-03 at 23:42 +0100, Simon Richter wrote:
> Hi,
>
> On 03.01.2016 23:32, Ben Hutchings wrote:
>
> > An initramfs is mandatory if using the standard kernel packages, as I
> > think most people do.
>
> Not on embedded systems.
Sure.
> While we do have the advantage there that the
>
On Sun, 2016-01-03 at 18:10 +0100, Iustin Pop wrote:
> On 2016-01-03 17:03:02, Simon McVittie wrote:
> > […] For
> > instance, /bin -> /usr/bin is needed because otherwise #!/bin/sh would
> > stop working, […]
>
> This brings to mind—I wonder if the performance impact of having /bin/sh
> be read t
On Sun, 2016-01-03 at 19:43 +0100, Marco d'Itri wrote:
> On Jan 03, Andreas Henriksson wrote:
>
> > First, it would be nice to have a preinst check if the system has any
> > running services that uses ProtectSystem and offer a choice to stop
> > (and restart) them in case having them running is r
On Sun, 2016-01-03 at 21:35 +0100, Christian Seiler wrote:
[...]
>
> Well, just for the heck of it I wrote a braindead-simple initrd
> implementation in just 300 LOC:
>
> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae
[...]
Neat. It should probably implement 'ro', 'rw' and 'rootdelay', t
On 01/04/2016 12:39 AM, Ben Hutchings wrote:
> On Sun, 2016-01-03 at 21:35 +0100, Christian Seiler wrote:
> [...]
>>
>> Well, just for the heck of it I wrote a braindead-simple initrd
>> implementation in just 300 LOC:
>>
>> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae
> [...]
>
> Neat.
On Mon, 2016-01-04 at 00:55 +0100, Christian Seiler wrote:
[...]
> Btw. initramfs-tools (via switch_root from util-linux) recursively
> deletes the files in the initramfs in a forked-off process right
> before exec()ing init. Is that really necessary? Shouldn't the
> kernel loose the data of the in
On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER wrote:
> Discussing infrastructure changes like what you're proposing (which I
> have no advice about) should usually be done through our mailing
> lists,
Which one would be the appropriate list?
I thought general would fit, as it likely affects m
Philippe Cerfon:
> On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER wrote:
>> Discussing infrastructure changes like what you're proposing (which I
>> have no advice about) should usually be done through our mailing
>> lists,
> Which one would be the appropriate list?
>
> I thought general would
72 matches
Mail list logo
