oat the scope of the systemd project so
it covers all previously existing use cases, which is a monumental
undertaking and would require design decisions that run counter to the
project's goals.
> Anyway, if you think that the merged /usr scheme is about systemd then
> you are automatically d
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
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
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 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
initramfs in some configurations does not break
compatibility nor causes significant troubles on upgrades.
> 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 tru
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 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
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
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 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
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
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
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
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
!
Forwarded Message
From: Steve Litt
To: d...@lists.dyne.org
Subject: Re: [DNG] FW: support for merged /usr in Debian
Date: Fri, 1 Jan 2016 12:07:34 -0500
On Fri, 01 Jan 2016 15:45:49 +0100
Micky Del Favero wrote:
> If I remember well Solaris has /bin linked to /usr/bin since many
> yea
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
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,
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,
* 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"
>
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
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...
I've upgraded to systemd have a separate /usr, and are
>> working without any issue whatsoever, this drivel can be safely ignored.
>
> Then what's the problem and why are we even having this conversation
> about merged /usr???
usr-merge isn't correcting the broken-ness of split-usr. Mounting a
separate "/usr" via the initramfs is the fix to that problem.
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 w
: nothing really sound except systemd wants it...
And again, this is not related to supporting a merged /usr scheme.
I think I gave you other reasons for not using an initrd that you have
not answered (other did also in the discussion) and other gave you
reasons to have /usr separated and not
these massive changes.
>
> And again, this is not related to supporting a merged /usr scheme.
>
That doesn't make sense given the subject you started this whole thread
with...
--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722
signature.asc
Description: OpenPGP digital signature
e amount of code needed to boot (more reliability, less
bugs). Manpower is limited.
The amount of brokenness of a separate /usr can also be witnessed by the
number of executables that had to migrate from /usr/bin to /bin. 115 on
my system (counting the symlinks).
Also, what other distributions do ma
y" is not a valid use case,
sorry.
And again, this is not related to supporting a merged /usr scheme.
--
ciao,
Marco
signature.asc
Description: PGP signature
e all
>>> the systems I've upgraded to systemd have a separate /usr, and are
>>> working without any issue whatsoever, this drivel can be safely ignored.
>>>
>> Then what's the problem and why are we even having this conversation
>> about mer
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
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 th
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
> > If what you claimed were true, then I'd agree with you, but since all
> > the systems I've upgraded to systemd have a separate /usr, and are
> > working without any issue whatsoever, this drivel can be safely ignored.
> >
> Then what's the problem and
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
at you claimed were true, then I'd agree with you, but since all
> the systems I've upgraded to systemd have a separate /usr, and are
> working without any issue whatsoever, this drivel can be safely ignored.
>
Then what's the problem and why are we even having this conversati
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
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
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.
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. I
only found the requirements that allow us to do usrmerge via
by design and
> needs to be fixed.
>
> Just because the separation occured way back in time, doesn't mean that
> it isn't still useful or beneficial for some or indeed many use cases.
>
> What I'd like to know is what are the real use cases where a merged /usr
>
ficial for some or indeed many use cases.
What I'd like to know is what are the real use cases where a merged /usr
is absolutely required (- where it isn't the result of a lazy and
unprofessional attitude of dis-respecting the environment that exists
and ignorance of the hard learne
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"
>> * "there was a question about /bin/kill and /usr/bin/killall be
not relevant for merged /usr.
--
ciao,
Marco
signature.asc
Description: PGP signature
, I have 4 of such systems running.
>Just to be clear: on a merged /usr system nothing prevents you from
>having /home and /var on standalone file systems and keeping the root
>file system (eventually with /usr on it) read only.
What is the "upgrade path" for an older system tha
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"
>* "there was a question about /bin/kill and /usr/bin/killall being
>inconsequent"
>* "we could not agree if p{erl,y
On Sat, 2 Jan 2016 19:00:17 +0100, m...@linux.it (Marco d'Itri) wrote:
>On Jan 02, Geert Stappers wrote:
>> A design with "whole OS on /usr" breaks the good pratice of having
>> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable.
>This is not a good practice but just an h
On Jan 02, Geert Stappers wrote:
> A design with "whole OS on /usr" breaks the good pratice of having
> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable.
This is not a good practice but just an historical accident: for details
see http://lists.busybox.net/pipermail/bu
right way to address this is
> > to make /etc a mount point.
> I am not aware of any plan to make /etc a mount point, which indeed
> would pointless.
> On a merged /usr system the root file system only contains /boot, /etc,
> /var and /home while the OS proper is all in /usr.
>
&
On Jan 02, Joerg Jaspert wrote:
> No, /etc can be nicely ro. That is, /, /usr, /etc, ... can be. The log
> storage and the user homes, as well as a tmp filesystem rw, rest ro.
> Works nicely, I have 4 of such systems running.
Just to be clear: on a merged /usr system nothing prevents
On 14173 March 1977, Ian Jackson wrote:
>> Is there any use case that requires supporting unmerged systems?
> Someone has already mentioned mounting /usr ro. But one generally has
> to keep /etc rw. I don't think that the right way to address this is
> to make /etc a mount point.
No, /etc can be
On Fri, 2016-01-01 at 20:55 +0800, Paul Wise wrote:
> On Fri, Jan 1, 2016 at 7:17 PM, Ansgar Burchardt wrote:
>
> > Moving /bin, /sbin, /lib to /usr has some advantages like being able to
> > mount /usr read-only while keeping /etc read-write. Or sharing /usr
> > between multiple containers and h
the popcon
count of usrmerge is not relevant.
It is doubly not relevant because their code is never triggered on
merged /usr systems, since the target files on them would not be
symlinks.
> Ok if a target or src file is a dpkg-divert it means admin has done
> some override.
> You do not kno
ointless.
On a merged /usr system the root file system only contains /boot, /etc,
/var and /home while the OS proper is all in /usr.
> Anotheer example: I have a system which does a rather hackish NFS root
> boot. It has its own / but uses /usr from the fileserver. This has
> worked surpr
Ian Jackson writes:
> Ansgar Burchardt writes ("Re: support for merged /usr in Debian"):
>> m...@linux.it (Marco d'Itri) writes:
>> > Thanks to my conversion program in usrmerge there is no need for a flag
>> > day, archive rebuilds or similar complexit
Hi,
On 01.01.2016 14:28, Vincent Bernat wrote:
>> Booting without an initrd, which is important for resource-constrained
>> embedded systems.
> Do you also require a separate /usr for those systems?
My current system doesn't, but I might need it in the future because
mounting /usr takes an awfu
Ansgar Burchardt writes ("Re: support for merged /usr in Debian"):
> m...@linux.it (Marco d'Itri) writes:
> > Thanks to my conversion program in usrmerge there is no need for a flag
> > day, archive rebuilds or similar complexity and we can even continue to
> &g
On Fri, Jan 1, 2016 at 2:22 PM, Bastien ROUCARIES
wrote:
> On Fri, Jan 1, 2016 at 10:46 AM, Marco d'Itri wrote:
>> On Dec 31, Bastien ROUCARIES wrote:
>>
>>> It is not only about lintian it is about the quality of your maintscript.
>> My maintscripts are a total of four commands and they have us
On Fri, Jan 1, 2016 at 10:46 AM, Marco d'Itri wrote:
> On Dec 31, Bastien ROUCARIES wrote:
>
>> It is not only about lintian it is about the quality of your maintscript.
> My maintscripts are a total of four commands and they have used for at
> least 9 months in packages with priority important (
On Fri, Jan 01, 2016 at 01:29:09PM +0100, Simon Richter wrote:
> On 01.01.2016 12:23, Ansgar Burchardt wrote:
>
> > Is there any use case that requires supporting unmerged systems?
>
> Booting without an initrd, which is important for resource-constrained
> embedded systems.
>
> [reasons for !ini
❦ 1 janvier 2016 13:29 +0100, Simon Richter :
>> Is there any use case that requires supporting unmerged systems?
>
> Booting without an initrd, which is important for resource-constrained
> embedded systems.
Do you also require a separate /usr for those systems?
--
The human race has one rea
On Fri, Jan 1, 2016 at 8:39 PM, Adam Borowski wrote:
> I don't think so. You already need the / filesystem, and with today storage
> sizes, if you can hold that, you can hold the whole system, period. Even on
> any embedded that can run Debian.
I'm reminded of the posts by Joey Hess in 2007:
h
On 2016-01-01 13:39:35, Adam Borowski wrote:
> On Fri, Jan 01, 2016 at 12:23:20PM +0100, Ansgar Burchardt wrote:
> > m...@linux.it (Marco d'Itri) writes:
> > > Thanks to my conversion program in usrmerge there is no need for a flag
> > > day, archive rebuilds or similar complexity and we can even c
On Fri, Jan 1, 2016 at 7:17 PM, Ansgar Burchardt wrote:
> Moving /bin, /sbin, /lib to /usr has some advantages like being able to
> mount /usr read-only while keeping /etc read-write. Or sharing /usr
> between multiple containers and having them only use a different / with
> different /etc and /v
On Fri, Jan 01, 2016 at 12:23:20PM +0100, Ansgar Burchardt wrote:
> m...@linux.it (Marco d'Itri) writes:
> > Thanks to my conversion program in usrmerge there is no need for a flag
> > day, archive rebuilds or similar complexity and we can even continue to
> > support unmerged systems.
>
> Is ther
we entered the "system
update" runlevel).
> It's simpler to support just merged-/usr and avoids the problem that
> sometimes a binary will be in both /bin and /usr/bin (with merged-/usr)
> and sometimes only in one location. That sounds like a source of bugs
> that have a g
t's simpler to support just merged-/usr and avoids the problem that
sometimes a binary will be in both /bin and /usr/bin (with merged-/usr)
and sometimes only in one location. That sounds like a source of bugs
that have a good potential to be found only too late...
Ansgar
Paul Wise writes:
> On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
>> https://wiki.debian.org/UsrMerge
>
> Now that we have union mounts in Linux, should we instead do what Ken
> Thompson and Dennis Ritchie should have done; install things in /
> instead of /usr and use union mounts when the
On Fri, Jan 01, 2016 at 06:20:42PM +0800, Paul Wise wrote:
> On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
>
> > https://wiki.debian.org/UsrMerge
>
> Now that we have union mounts in Linux, should we instead do what Ken
> Thompson and Dennis Ritchie should have done; install things in /
>
On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote:
> https://wiki.debian.org/UsrMerge
Now that we have union mounts in Linux, should we instead do what Ken
Thompson and Dennis Ritchie should have done; install things in /
instead of /usr and use union mounts when there is one small disk
contain
On Dec 31, Bastien ROUCARIES wrote:
> It is not only about lintian it is about the quality of your maintscript.
My maintscripts are a total of four commands and they have used for at
least 9 months in packages with priority important (nano) and required
(debianutils), with no problems reported.
On 30 December 2015 at 22:51, Marco d'Itri wrote:
> We have a reasonably tested usrmerge package which can be used to
> convert on the fly a system to merged /usr, and the good news is that
> there are only three packages which need to be fixed to work on a merged
> /usr system.
On Thu, Dec 31, 2015 at 3:22 PM, Marco d'Itri wrote:
> On Dec 31, Bastien ROUCARIES wrote:
>
>> Yes I have some question. You do not answered point given in #767754
>> about dpkg-divert. Moreover guillem and me consider that symlinking
>> lib is evil.
> Because I still do not really understand yo
On Dec 31, Bastien ROUCARIES wrote:
> Yes I have some question. You do not answered point given in #767754
> about dpkg-divert. Moreover guillem and me consider that symlinking
> lib is evil.
Because I still do not really understand your objections nor which
problems you are trying to solve, so
On Thu, Dec 31, 2015 at 1:30 PM, Marco d'Itri wrote:
> On Dec 31, Marc Haber wrote:
>
>> Please consider keeping support for separate /usr as it is done today.
>> Mounting /usr in initrd is an acceptable workaround.
> The whole point of the merged /usr scheme is to supp
On Dec 31, Marc Haber wrote:
> Please consider keeping support for separate /usr as it is done today.
> Mounting /usr in initrd is an acceptable workaround.
The whole point of the merged /usr scheme is to support a separate /usr
file system, except that this way it is actually useful b
On Thu, 31 Dec 2015 01:51:45 +0100, m...@linux.it (Marco d'Itri) wrote:
>We have a reasonably tested usrmerge package which can be used to
>convert on the fly a system to merged /usr, and the good news is that
>there are only three packages which need to be fixed to work on a
We have a reasonably tested usrmerge package which can be used to
convert on the fly a system to merged /usr, and the good news is that
there are only three packages which need to be fixed to work on a merged
/usr system.
Thanks to my conversion program in usrmerge there is no need for a flag
601 - 677 of 677 matches
Mail list logo
