Re: /usrmove and path ordering

2012-02-16 Thread Jason L Tibbitts III
> "SS" == Simo Sorce writes: SS> I guess it is time to change habits, what's the point of a separate SS> /usr these days ? I also always configured a separate /usr until I decided to obey systemd's complaints about it being broken (though of course I never had any issue at all with it). For

Re: /usrmove and path ordering

2012-02-16 Thread Jim Meyering
Simo Sorce wrote: > On Thu, 2012-02-16 at 13:22 +0100, Jim Meyering wrote: ... >> Prior to F17, I've always put /usr on a partition separate from /. >> >> $ df -hT / /usr >> Filesystem Type Size Used Avail Use% Mounted on >> /dev/sda4 ext4 11G 7.3G 3.2G 70% / >> /dev

Re: /usrmove and path ordering

2012-02-16 Thread Simo Sorce
On Thu, 2012-02-16 at 13:22 +0100, Jim Meyering wrote: > Reindl Harald wrote: > > Am 15.02.2012 13:43, schrieb Martin Langhoff: > >> On Feb 15, 2012 6:16 AM, "Reindl Harald" >> > wrote: > >>> there is no single reason for a feature like /usrmove which > >>> in fact n

Re: /usrmove and path ordering

2012-02-16 Thread Reindl Harald
Am 16.02.2012 13:22, schrieb Jim Meyering: > Reindl Harald wrote: >> Am 15.02.2012 13:43, schrieb Martin Langhoff: >>> On Feb 15, 2012 6:16 AM, "Reindl Harald" >> > wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at

Re: /usrmove and path ordering

2012-02-16 Thread Jim Meyering
Reindl Harald wrote: > Am 15.02.2012 13:43, schrieb Martin Langhoff: >> On Feb 15, 2012 6:16 AM, "Reindl Harald" > > wrote: >>> there is no single reason for a feature like /usrmove which >>> in fact nobody NEEDS at all and definitly not now to press >>> it into the n

Re: /usrmove and path ordering

2012-02-15 Thread Kevin Kofler
Martin Langhoff wrote: > Miroslav -- you haven't seen this work because the tasks are not all > yet in. But the "stateless" feature handles a lot of it already. If you revert /usr to a snapshot without touching the rpmdb (in /var/lib/rpm), your system will be in a very inconsistent state.

Re: /usrmove and path ordering

2012-02-15 Thread Martin Langhoff
On Wed, Feb 15, 2012 at 8:30 AM, Reindl Harald wrote: > Am 15.02.2012 14:25, schrieb Miloslav Trmač: >> I haven't seen this work and I don't think such snaphots can be relied >> upon: /boot, /etc and /var are affected by installs as well Miroslav -- you haven't seen this work because the tasks ar

Re: /usrmove and path ordering

2012-02-15 Thread Reindl Harald
Am 15.02.2012 14:25, schrieb Miloslav Trmač: > On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff > wrote: >> You are wrong. The /usr move has a very clear impact in being able to >> snapshot your OS install partition. Add btrfs, yum hooks and the >> already-implemented "stateless" configuration a

Re: /usrmove and path ordering

2012-02-15 Thread Miloslav Trmač
On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff wrote: > You are wrong. The /usr move has a very clear impact in being able to > snapshot your OS install partition. Add btrfs, yum hooks and the > already-implemented "stateless" configuration and you have a really major > feature: a fully upgrade/

Re: /usrmove and path ordering

2012-02-15 Thread Reindl Harald
Am 15.02.2012 13:43, schrieb Martin Langhoff: > On Feb 15, 2012 6:16 AM, "Reindl Harald" > wrote: >> there is no single reason for a feature like /usrmove which >> in fact nobody NEEDS at all and definitly not now to press >> it into the next release with pressure

Re: /usrmove and path ordering

2012-02-15 Thread Martin Langhoff
On Feb 15, 2012 6:16 AM, "Reindl Harald" wrote: > there is no single reason for a feature like /usrmove which > in fact nobody NEEDS at all and definitly not now to press > it into the next release with pressure You are wrong. The /usr move has a very clear impact in being able to snapshot your O

Re: /usrmove and path ordering

2012-02-15 Thread Reindl Harald
Am 15.02.2012 12:24, schrieb Tomasz Torcz: > On Wed, Feb 15, 2012 at 12:16:07PM +0100, Reindl Harald wrote: >> >> there is no single reason for a feature like /usrmove which >> in fact nobody NEEDS at all and definitly not now to press >> it into the next release with pressure > > Well, I need u

Re: /usrmove and path ordering

2012-02-15 Thread Tomasz Torcz
On Wed, Feb 15, 2012 at 12:16:07PM +0100, Reindl Harald wrote: > > there is no single reason for a feature like /usrmove which > in fact nobody NEEDS at all and definitly not now to press > it into the next release with pressure Well, I need usrmove, because I have a strong need for clean syste

Re: /usrmove and path ordering

2012-02-15 Thread Reindl Harald
Am 15.02.2012 12:05, schrieb Harald Hoyer: > Am 15.02.2012 11:20 schrieb "Ralf Corsepius" >: >> Yes. We've forked f17 and you guys are still chasing elementary bugs. >> >> What do you expect Fedora users to think of this? It communicates a nice >> impression of the q

Re: /usrmove and path ordering

2012-02-15 Thread FRank Murphy
On 15/02/12 10:18, Ralf Corsepius wrote: So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your w

Re: /usrmove and path ordering

2012-02-15 Thread Harald Hoyer
Am 15.02.2012 11:20 schrieb "Ralf Corsepius" : > Yes. We've forked f17 and you guys are still chasing elementary bugs. > > What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. > > Better stop this non-sense now rofl... "nothing else is b

Re: /usrmove and path ordering

2012-02-15 Thread Reindl Harald
Am 15.02.2012 11:25, schrieb drago01: >>> So? Should we drop all features that aren't bug free after feature freeze? >> >> Yes. We've forked f17 and you guys are still chasing elementary bugs. > > "elementary bugs" ? You got to be either kidding or trolling. > >> What do you expect Fedora users

Re: /usrmove and path ordering

2012-02-15 Thread drago01
On Wed, Feb 15, 2012 at 11:18 AM, Ralf Corsepius wrote: > On 02/15/2012 10:37 AM, drago01 wrote: >> >> On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler >>  wrote: >>> >>> Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requir

Re: /usrmove and path ordering

2012-02-15 Thread Ralf Corsepius
On 02/15/2012 10:37 AM, drago01 wrote: On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler wrote: Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requirement. You call it an "optimization", I call it fixing a pessimization (performance r

Re: /usrmove and path ordering

2012-02-15 Thread drago01
On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler wrote: > Lennart Poettering wrote: >> Because dropping these dirs from the search paths is merely an >> optimization, not a requirement. > > You call it an "optimization", I call it fixing a pessimization (performance > regression). > > And as the orig

Re: /usrmove and path ordering

2012-02-14 Thread Kevin Kofler
Lennart Poettering wrote: > Because dropping these dirs from the search paths is merely an > optimization, not a requirement. You call it an "optimization", I call it fixing a pessimization (performance regression). And as the original message in the thread points out, the regression actually a

Re: /usrmove and path ordering

2012-02-14 Thread Lennart Poettering
On Tue, 14.02.12 23:08, Kevin Kofler (kevin.kof...@chello.at) wrote: > Ondrej Vasik wrote: > > You are right, setup update fixed only /sbin locations... /bin has to be > > done on glibc and shells side. Sorry for confusion... > > WHY was UsrMove allowed to be merged in such broken and incomplete

Re: /usrmove and path ordering

2012-02-14 Thread Kevin Kofler
Ondrej Vasik wrote: > You are right, setup update fixed only /sbin locations... /bin has to be > done on glibc and shells side. Sorry for confusion... WHY was UsrMove allowed to be merged in such broken and incomplete state? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.o

Re: /usrmove and path ordering

2012-02-14 Thread Ondrej Vasik
- Original Message - > On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote: > > On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Dear developers, > > > > > > Now that the /usrmove changes have landed i

Re: /usrmove and path ordering

2012-02-14 Thread Adam Williamson
On Tue, 2012-02-14 at 17:33 +0100, Tomas Mraz wrote: > On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote: > > On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Dear developers, > > > > > > Now that the /usrm

Re: /usrmove and path ordering

2012-02-14 Thread Tomas Mraz
On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote: > On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Dear developers, > > > > Now that the /usrmove changes have landed in the F-17 branch, should > > the ordering o

Re: /usrmove and path ordering

2012-02-14 Thread Michel Alexandre Salim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/2012 05:11 PM, Ondrej Vasik wrote: > On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Dear developers, >> >> Now that the /usrmove changes have landed in the F-17 branch,

Re: /usrmove and path ordering

2012-02-14 Thread Ondrej Vasik
On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dear developers, > > Now that the /usrmove changes have landed in the F-17 branch, should > the ordering of directories in PATH be changed? /usr/bin should appear > before /bin a

/usrmove and path ordering

2012-02-14 Thread Michel Alexandre Salim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear developers, Now that the /usrmove changes have landed in the F-17 branch, should the ordering of directories in PATH be changed? /usr/bin should appear before /bin and /usr/sbin before /sbin. Right now $(which a-binary) would report that all /us