d to
wait a release before doing that so we don't add tons of dependencies
on the intramfs version.
3) wait a release (unless we do that for 2)
4) remove all / instead of /usr patches, remove / + /usr duplicates
5) wait a release
6) consider the / + /usr situation again
That would give at l
On Fri, May 10, 2013 at 10:07:18AM +0200, Marc Haber wrote:
> On Thu, 9 May 2013 18:17:29 +0200, m...@linux.it (Marco d'Itri) wrote:
> >On May 09, "Bernhard R. Link" wrote:
> >> Or in other words: to make essential functionality not available if
> >> /usr is broken.
> >Again: this is not we are di
On May 12, Stéphane Glondu wrote:
> What about /etc ? /var ? both contain data that can mess up with a
> running system...
The goal (or at least, a possible one) is to be able to update the
operating system (or to snapshot it) while keeping your data and
configurations.
The most obvious of /var
2013/5/12 Stéphane Glondu :
> What about /etc ? /var ? both contain data that can mess up with a
> running system...
All go into a snapshot.
That's why I stand for moving /var/lib/mysql and similar things out of /var
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subj
Le 11/05/2013 20:05, Aron Xu a écrit :
> An easy example is that, on Solaris, there is a something called boot
> environment (BE), which is essentially snapshots of the combination of
> /usr and /boot, users can switch between different BEs easily without
> affecting any user data. Without /usr mer
, doing such work could be
> much more complicated because user data and system data is mixed in
> the file system's hierarchy, it's hard to make sure switching between
> different snapshots won't change user data.
Aron, merging / and /usr is not related to the ability of
On Wed, May 8, 2013 at 12:52 AM, Marco d'Itri wrote:
> On May 07, Jonathan Dowland wrote:
>
>> > If we do this, I'd prefer to make /usr a symlink to / on new installs
>> I've always thought that myself, but it seems most folks who are pro
>> merge tend to propose going the other way. I've never u
On Sat, May 11, 2013 at 04:06:38PM +, Thorsten Glaser wrote:
> And I absolutely do not buy the argument that Debian does not
> have enough manpower to keep the / vs. /usr separation (for many
> use cases) working.
https://lists.debian.org/debian-devel/2012/08/msg00858.html
When you've demon
for the “right” (way of developing a UNIX system) instead
of working yourself on making things better.
> Ensuring /usr is mounted at boot time is one thing. It provides
> certain very useful guarantees which we currently don't have. Merging
> / and /usr is another matter entirely, and i
w, to me, from the discussion, it looks like the lower-right
corner is the only one doing actual work, and the only one in question,
and that the two upper lines are “a given” even by the upstreams in
question. Merging / and /usr, one way or the other, has never been
mentioned as a requirement as long
On Fri, 10 May 2013 19:38:22 +0200, m...@linux.it (Marco d'Itri) wrote:
>So this confirms that a live system like GRML is a good replacement for
>a rescue system, looks like we solved another use case.
You are trying to turn my word around. Bad style of discussion. EOD on
my part, it's another wa
On May 10, Marc Haber wrote:
> Additional work necessary to satisfy upstream's bizarre ideas. Why not
> keeping things the way they are now? They work. No need to waste
> developer time.
Why make new releases? bo worked fine, there is no need for new features.
> >People use live CDs for rescue a
On Fri, 10 May 2013 11:48:37 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 10, Marc Haber wrote:
>> Having the rescue image _this_ independent is not really desireable
>> since one would probably have to deal with outdated or non-existing
>> rescue tools in the independent image while the cor
On Fri, 2013-05-10 at 14:46 +0100, Roger Leigh wrote:
> On Fri, May 10, 2013 at 03:04:34PM +0200, Olav Vitters wrote:
> > On Thu, May 09, 2013 at 02:08:05PM +0200, Marc Haber wrote:
> > > You have a point here. The problem is that people need to change their
> > > operations, which is hard for many
ugh. This is ultimately being driven by
uncooperative upstreams unwilling to maintain their stuff properly, and
this really means udev, and this is part of systemd for better or worse.
Well, worse.
Ensuring /usr is mounted at boot time is one thing. It provides
certain very useful guarantees
On Tue, May 07, 2013 at 10:23:52PM +, Thorsten Glaser wrote:
> Gah! Just because the other FLOS idiots are doing it doesn’t mean
> Debian should follow.
Do you also have technical objections or some kind of reasoning behind
this?
--
Regards,
Olav
--
To UNSUBSCRIBE, email to debian-devel-r
On Thu, May 09, 2013 at 02:08:05PM +0200, Marc Haber wrote:
> You have a point here. The problem is that people need to change their
> operations, which is hard for many people, let alone the case when
> emergency manuals need to be changed just for the sake of satisfying
> Lennart.
There are vari
On May 10, Marc Haber wrote:
> Having the rescue image _this_ independent is not really desireable
> since one would probably have to deal with outdated or non-existing
> rescue tools in the independent image while the correct software in
> the correct version is on the system's own / file system
On Thu, 9 May 2013 18:17:29 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 09, "Bernhard R. Link" wrote:
>> Or in other words: to make essential functionality not available if
>> /usr is broken.
>Again: this is not we are discussing. Essential functionality is moving
>to /usr anyway
Which is
On Thu, 9 May 2013 15:50:45 +0200, Philipp Kern
wrote:
>On Thu, May 09, 2013 at 10:32:09AM +0200, Marc Haber wrote:
>> That's how I do it for new installs. However, this is vastly more
>> complex than the traditional setup, and it doesn't help for systems in
>> maintenance mode that, for example,
On May 09, "Bernhard R. Link" wrote:
> Or in other words: to make essential functionality not available if
> /usr is broken.
Again: this is not we are discussing. Essential functionality is moving
to /usr anyway, no matter if /bin will become a symlink to /usr/bin.
> Having a seperate / means y
* Roger Leigh [130509 13:34]:
> The assumptions here are that a separate rootfs decreases the chance
> of breakage, and that you'll need the rootfs to perform the rescue.
No, the point is that having two file systems reduces the amout of
breakage you get.
All the important stuff is in / while /u
* Marco d'Itri [130509 16:03]:
> So, please let me know if you have some technical objections better
> than "it's an hack".
Having a seperate / means you have an instant rescue image that has
just the right kernel and tools you need to repair the rest of your
system. You also have one small file
On May 09, Marc Haber wrote:
> If you don't care about the companies that use Debian and you want
> their sponsoring money to go elsewhere, yes, absolutely do this.
Actually I care a lot, since I happen to have a role in one which
manages quite a bit of Debian servers (four digits of Debian serv
On Thu, May 09, 2013 at 10:32:09AM +0200, Marc Haber wrote:
> That's how I do it for new installs. However, this is vastly more
> complex than the traditional setup, and it doesn't help for systems in
> maintenance mode that, for example, cannot be changed because of
> service level agreements and
Marc Haber writes:
> Isn't that the one that doesn't even have a shell history or tab
> completion?
At least in squeeze I have both. Try booting with e.g. break=top to see
yourself.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Cont
On Thu, 9 May 2013 10:40:14 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 09, Marc Haber wrote:
>> That's a hack which is acceptable for single-user home desktops. We're
>> talking about professional IT here.
>Great, if this is the strongest objection you have then looks like it
>can be done
On Thu, 9 May 2013 12:33:47 +0100, Roger Leigh
wrote:
>Regarding rescue, the initramfs has a rescue shell which I've found
>to be just as useful as single user mode.
Isn't that the one that doesn't even have a shell history or tab
completion?
>Once it has mounted the
>rootfs, you can chroot into
On Wed, May 08, 2013 at 08:14:32PM +0200, Marc Haber wrote:
> On Wed, 8 May 2013 17:32:13 +0200, Helmut Grohne
> wrote:
> >On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
> >> Fedora updates are different. (And so are Ubuntu updates, if one considers
> >> that it's possible to provid
On Thu, May 09, 2013 at 11:50:31AM +0200, Goswin von Brederlow wrote:
> If you make /usr a symlink to / then there will be to distinct paths
> to each file and that will confuse dpkg.
>
> The first problem that comes to mind is package A containing /bin/foo
> and package B containing /usr/bin/foo.
On Wed, May 08, 2013 at 09:12:12AM -0400, The Wanderer wrote:
> On 05/07/2013 11:41 AM, Paul Tagliamonte wrote:
>
> >On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote:
> >
> >>On May 07, Paul Tagliamonte wrote:
> >>
> >>>No please. We are good about making sure they each mean something
On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote:
> On Tue, May 07, 2013 at 05:35:11PM +0200, Marco d'Itri wrote:
> > On May 07, ?? ?? wrote:
> >
> > > What about merging / and /usr ?
> > An ambitious plan.
> > I strongly sup
On May 09, Marc Haber wrote:
> That's a hack which is acceptable for single-user home desktops. We're
> talking about professional IT here.
Great, if this is the strongest objection you have then looks like it
can be done.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Thu, 9 May 2013 03:43:44 +0200, m...@linux.it (Marco d'Itri) wrote:
>Let's assume that at this point there are no files in /{bin,sbin,lib}
>which have the same name of a file in /usr/{bin,sbin,lib} but are not
>a symlink to them (which I suspect is something that we want anyway).
>
>For each $
On Thu, 9 May 2013 03:31:30 +0200, m...@linux.it (Marco d'Itri) wrote:
>This is not relevant for what we are talking about because /usr *will*
>be required be available to boot the system no matter where the files
>currently in /{bin,sbin,lib} will end up.
Yes. That is really bad news and I hate
On Thu, 2013-05-09 at 03:43 +0200, Marco d'Itri wrote:
> On May 08, Marc Haber wrote:
>
> > How would that be done for a 200 MB filesystem holding /, no extra
> > /boot partition, and a multi-gigabyte /usr beyond the 2T barrier?
> Let's assume that at this point there are no files in /{bin,sbin,l
On May 08, Marc Haber wrote:
> How would that be done for a 200 MB filesystem holding /, no extra
> /boot partition, and a multi-gigabyte /usr beyond the 2T barrier?
Let's assume that at this point there are no files in /{bin,sbin,lib}
which have the same name of a file in /usr/{bin,sbin,lib} bu
On May 08, Marc Haber wrote:
> If we force a much bigger /, the chance of a broken / filesystem
> increases. If / is fine, one has a chance to fix the system without
> booting to rescue. So, a small / both decreases the probability of a
> boot failure and makes fixing breakage easier.
>
> If we
On Wed, 8 May 2013 17:32:13 +0200, Helmut Grohne
wrote:
>On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
>> Fedora updates are different. (And so are Ubuntu updates, if one considers
>> that it's possible to provide fixup scripts to update-manager pre-upgrade.)
>> As long as we're su
On Wed, 8 May 2013 01:06:41 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 07, Marc Haber wrote:
>> >What about merging / and /usr ?
>> So we really want to explicitly not offer an upgade path from wheezy
>> to jessie?
>This causes no major issues on upgrades
On Wed, May 08, 2013 at 05:32:13PM +0200, Helmut Grohne wrote:
> On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
> > Fedora updates are different. (And so are Ubuntu updates, if one considers
> > that it's possible to provide fixup scripts to update-manager pre-upgrade.)
> > As long a
On Wed, May 08, 2013 at 05:32:13PM +0200, Helmut Grohne wrote:
> So really what does it take to e.g. move /bin and stuff to /usr? Did
> anyone try that? Where is that documented? What problems did occur?
http://fedoraproject.org/wiki/Features/UsrMove
--
WBR, wRAR
--
To UNSUBSCRIBE, email to deb
On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
> Fedora updates are different. (And so are Ubuntu updates, if one considers
> that it's possible to provide fixup scripts to update-manager pre-upgrade.)
> As long as we're supporting upgrades through plain apt, that's going to
> be har
On May 08, The Wanderer wrote:
> The "emergency tools" side of it I'm less clear on. It's relatively
apt-get install grml-rescueboot
Which is way safer than relying on / working.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Wed, May 08, 2013 at 09:12:12AM -0400, The Wanderer wrote:
> The question, expressed in a number of different ways to provide a type
> of "clarity by triangulation", is: Why does /usr exist in the first
> place? Why was it created, way back in the day? What is its purpose,
> what is it for?
Hist
On 05/07/2013 11:41 AM, Paul Tagliamonte wrote:
On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote:
On May 07, Paul Tagliamonte wrote:
No please. We are good about making sure they each mean something
important, and there's no good reason.
Not really nowadays: more and more thin
On Wed, May 08, 2013 at 01:06:41AM +0200, Marco d'Itri wrote:
> On May 07, Marc Haber wrote:
> > >What about merging / and /usr ?
> > So we really want to explicitly not offer an upgade path from wheezy
> > to jessie?
> This causes no major issues on upgrades, Fe
On May 07, Marc Haber wrote:
> >What about merging / and /usr ?
> So we really want to explicitly not offer an upgade path from wheezy
> to jessie?
This causes no major issues on upgrades, Fedora did it.
The hard part is replacing with a symlink to the other one of every pair
of bi
Marco d'Itri Linux.IT> writes:
> On May 07, Игорь Пашев gmail.com> wrote:
>
> > What about merging / and /usr ?
Absolutely not, and I’ll support a GR against it.
> I strongly support the "everything in /usr" scheme, but let's first
Absolutely not
On Martes, 7 de mayo de 2013 17:26:09 Simon Chopin wrote:
> Quoting Jonathan Dowland (2013-05-07 18:15:46)
>
> > This has been discussed many times on -devel, including before you became
> > a DD.
>
> Please don't assume that only DDs read debian-devel. I would think that
> most aspiring DDs were
On Wed, May 08, 2013 at 01:43:03AM +0800, Thomas Goirand wrote:
> On 05/08/2013 12:40 AM, Steve Langasek wrote:
> > On Tue, May 07, 2013 at 11:34:20AM -0400, Paul Tagliamonte wrote:
> >> On Tue, May 07, 2013 at 07:31:36PM +0400, Игорь Пашев wrote:
> >>> What abou
On Tue, May 07, 2013 at 06:57:12PM +0100, Jonathan Dowland wrote:
> On Tue, May 07, 2013 at 07:21:26PM +0200, Stefano Zacchiroli wrote:
> > I don't see why, in this context, that's a useful heuristic to have. If
> > you want to debunk someone's argument,
>
> I'm not sure I'd characterize what I tr
On Tue, May 07, 2013 at 07:21:26PM +0200, Stefano Zacchiroli wrote:
> I don't see why, in this context, that's a useful heuristic to have. If
> you want to debunk someone's argument,
I'm not sure I'd characterize what I tried to get across as debunking someone's
argument. More so, questioning whet
On Tue, 7 May 2013 19:31:36 +0400, ? ?
wrote:
>What about merging / and /usr ?
So we really want to explicitly not offer an upgade path from wheezy
to jessie?
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Ha
On 05/08/2013 12:40 AM, Steve Langasek wrote:
> On Tue, May 07, 2013 at 11:34:20AM -0400, Paul Tagliamonte wrote:
>> On Tue, May 07, 2013 at 07:31:36PM +0400, Игорь Пашев wrote:
>>> What about merging / and /usr ?
>> No please. We are good about making sure they each mea
On Tue, May 07, 2013 at 05:57:19PM +0100, Jonathan Dowland wrote:
> > Please don't assume that only DDs read debian-devel.
>
> Don't worry, I haven't: I just don't know of a more accurate heuristic
> for determining when somebody started to get involved.
I don't see why, in this context, that's a
On 7 May 2013, at 17:26, Simon Chopin wrote:
> Please don't assume that only DDs read debian-devel.
Don't worry, I haven't: I just don't know of a more accurate heuristic for
determining when somebody started to get involved.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wi
On May 07, Jonathan Dowland wrote:
> > If we do this, I'd prefer to make /usr a symlink to / on new installs
> I've always thought that myself, but it seems most folks who are pro
> merge tend to propose going the other way. I've never understood why.
I was trying to not start a new discussion ab
On 07/05/13 17:17, Jonathan Dowland wrote:
> On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote:
>> If we do this, I'd prefer to make /usr a symlink to / on new installs
>
> I've always thought that myself, but it seems most folks who are pro
> merge tend to propose going the other way.
On Tue, May 07, 2013 at 11:34:20AM -0400, Paul Tagliamonte wrote:
> On Tue, May 07, 2013 at 07:31:36PM +0400, Игорь Пашев wrote:
> > What about merging / and /usr ?
> No please. We are good about making sure they each mean something
> important,
No, we're actually terrible
Quoting Jonathan Dowland (2013-05-07 18:15:46)
> This has been discussed many times on -devel, including before you became a
> DD.
Please don't assume that only DDs read debian-devel. I would think that
most aspiring DDs were following it long before even applying in NM.
signature.asc
Descripti
On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote:
> That said, I'm not in support of moving things to /usr; it's completely
> backward.
…
> If we do this, I'd prefer to make /usr a symlink to / on new installs
I've always thought that myself, but it seems most folks who are pro
merge te
Hi Paul,
This has been discussed many times on -devel, including before you became a DD.
Many people, including Roger and Marco, have spent a *lot* of time thinking
about this and working on proofs of concepts, etc. already. Please take some
time to read up on the previous threads before insisting
On May 07, Paul Tagliamonte wrote:
> > "everything in /usr" actually means that supporting these devices is
> > much easier.
> Not when you have a 500 meg internal storage that the firmware boots off
> of, and using a multi-gig CF card to store the mega-awesome-app you're
> using it for.
It's mu
On Tue, May 07, 2013 at 05:35:11PM +0200, Marco d'Itri wrote:
> On May 07, Игорь Пашев wrote:
>
> > What about merging / and /usr ?
> An ambitious plan.
> I strongly support the "everything in /usr" scheme, but let's first
> consolidate support fo
2013/5/7 Paul Tagliamonte :
> Not when you have a 500 meg internal storage that the firmware boots off
> of, and using a multi-gig CF card to store the mega-awesome-app you're
> using it for.
Similar to Live CDs where /usr used to be compressed on a CD?
http://cgit.osdyson.org/live.git/tree/proto
On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote:
> On May 07, Paul Tagliamonte wrote:
>
> > No please. We are good about making sure they each mean something
> > important, and there's no good reason.
> Not really nowadays: more and more things needed at boot time are in
> /usr and
On May 07, Paul Tagliamonte wrote:
> No please. We are good about making sure they each mean something
> important, and there's no good reason.
Not really nowadays: more and more things needed at boot time are in
/usr and there are no plans to "fix" them.
> We also support setups that might nee
On May 07, Игорь Пашев wrote:
> What about merging / and /usr ?
An ambitious plan.
I strongly support the "everything in /usr" scheme, but let's first
consolidate support for "standalone /usr must be mounted by the
initramfs".
--
ciao,
Marco
signature.asc
Description: Digital signature
On Tue, May 07, 2013 at 07:31:36PM +0400, Игорь Пашев wrote:
> What about merging / and /usr ?
No please. We are good about making sure they each mean something
important, and there's no good reason.
We also support setups that might need this split due to low storage,
such as arm
What about merging / and /usr ?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CALL-Q8zwv5QtT05VA+cQg+OF=paijrt606x2shdte+b4qv2...@mail.gmail.com
71 matches
Mail list logo
