Re: /usrmove and path ordering
Reindl Harald wrote: Am 15.02.2012 13:43, schrieb Martin Langhoff: On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net 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 OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. only one out of a million installations have /usr seperated from / and the default is NOT do this - so no there is no impact on any normal setup 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/sda6 ext4 10G 7.3G 2.3G 77% /usr I know I'm special ;-), but *that* special? I doubt it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 h.rei...@thelounge.net mailto:h.rei...@thelounge.net 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 OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. only one out of a million installations have /usr seperated from / and the default is NOT do this - so no there is no impact on any normal setup 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/sda6 ext4 10G 7.3G 2.3G 77% /usr I know I'm special ;-), but *that* special? I doubt it. I guess it is time to change habits, what's the point of a separate /usr these days ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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/sda6 ext4 10G 7.3G 2.3G 77% /usr I know I'm special ;-), but *that* special? I doubt it. I guess it is time to change habits, what's the point of a separate /usr these days ? I like to keep / very small, separate and mostly read-only, so that when something goes wrong with the disk it's less likely to affect the root partition, so I'm all for the implicit writable/read-only segregation this implies. /usrmove is a clear win. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
SS == Simo Sorce s...@redhat.com 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 me it was simply keeping / small and being able to back it up easily without backing up all of the stuff in /usr. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler kevin.kof...@chello.at 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 original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). So? Should we drop all features that aren't bug free after feature freeze? You complain as if we are going to release GA tomorrow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On 02/15/2012 10:37 AM, drago01 wrote: On Wed, Feb 15, 2012 at 1:26 AM, Kevin Koflerkevin.kof...@chello.at 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 original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). 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 works. Better stop this non-sense now! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 11:18 AM, Ralf Corsepius rc040...@freenet.de wrote: On 02/15/2012 10:37 AM, drago01 wrote: On Wed, Feb 15, 2012 at 1:26 AM, Kevin Koflerkevin.kof...@chello.at 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 original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). 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 to think of this? We are at pre alpha / alpha ... users should not have to care about that right now. It communicates a nice impression of the quality of your works. I am not involved in this so it is not my works ... Better stop this non-sense now! The only nonsense I see here is people ranting for the sake of ranting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 to think of this? We are at pre alpha / alpha ... users should not have to care about that right now. It communicates a nice impression of the quality of your works. I am not involved in this so it is not my works ... Better stop this non-sense now! The only nonsense I see here is people ranting for the sake of ranting. people are ranting because the experience how buggy are features in the GA-releases if they are in such a not conesquently thought state at alpha the last releases it was always fact that they was not ready until GA and if they can't be fixed then common bugs are listed in the release notes the problem is here that first the work/change/feature is started as happend often in the past and in the middle of the work more and more people coming with things nobody cared in tghe planning phase what let many of us feel like there is nothing planned, there were people starting and forcing without any thoughts and the hope that all will get sorted until GA signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 11:20 schrieb Ralf Corsepius rc040...@freenet.de: 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 broken and my PATH is non-optimal, stop the usrmove, because I don't want it. this is so ridicoulus... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 works. Better stop this non-sense now! I'm a user, don't have a problem. -- Regards FRank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 12:05, schrieb Harald Hoyer: Am 15.02.2012 11:20 schrieb Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de: 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 broken and my PATH is non-optimal, stop the usrmove, because I don't want it. the nothing else we will see later fact is that the feauture is included and now people are coming did we think about this and this and this... 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 this feels like you guys has no other things to do and sitting there hmm let us search for solutions press into a release and let us search for constructed problems the solution may solve to have any valid reason to do it now signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 system. Here, your point is invalid. Harald, you are generating copius amounts of stop-energy. You really should participate in Fedora process as it designed - during feature proposals, discussions, implementation. Right now you are ranting post factum. The amount of time you waste on this mail list is huge, and it is a sad waste. It would be better spent on filling bugs on real issues. Because bugs, you know, get fixed. I even remember one bug that you have filled about some deamon not shipping a systemd unit. I saw this bug, I've created and attached unit file, it got shipped by maintainer. Case closed. This is the best way of participation. Your baseless, repetitive rants finally made me blacklist you. It's very sad for me, as I believe in open participation and meritocracy. Good bye, -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. pgpsRQfuuDJox.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 usrmove, because I have a strong need for clean system. Here, your point is invalid. you mean all existing linux-installations are unclean? you need a clean system but accept that half of the distribution is a mix of systemd/sysv/lsb - you would get a clean system if the work of one feature would be COMPLETLY done before the next is started, but seems that most people have no intention nor the make nor any idea what is a clean system signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net 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 OS install partition. Add btrfs, yum hooks and the
already-implemented stateless configuration and you have a really major
feature: a fully upgrade/test/rollback setup for Fedora.
For OLPC for example, this could be a major win, hence my interest. I
definitely want it for my laptop. I'm sure many running rawhide will want
it :-) -- upgrade/test/file bugs if it breaks/rollback if it's real bad.
cheers,
m
{ Martin Langhoff - one laptop per child }
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 13:43, schrieb Martin Langhoff: On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net 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 OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. only one out of a million installations have /usr seperated from / and the default is NOT do this - so no there is no impact on any normal setup signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff martin.langh...@gmail.com 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/test/rollback setup for Fedora. 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 (especially in the cases where you would want to roll back); I don't think anybody wants exactly the separation provided by the crude /usr vs. rest that is provided by the /usr move. And snapshots that can not be relied upon may be even worse than no snapshots if they motivate users to skip creating proper backups. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 14:25, schrieb Miloslav Trmač: On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff martin.langh...@gmail.com 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/test/rollback setup for Fedora. 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 (especially in the cases where you would want to roll back); I don't think anybody wants exactly the separation provided by the crude /usr vs. rest that is provided by the /usr move. this is a additional reason why the /usrmove is completly useless because it suggests users they are save using any FS-snapshot have many fun after a big upgrade to revert the snapshot if you really have /usr on a seperated FS and your /etc and /var/lib/rpm will stay in the state after the upgrade and your FS is bombed back so for users having a default setup there is no difference because / as /etc and /usr is the same FS and for ones have seperated /usr it does not bring any benefit in real life with other words: the whole work which is done here is useless and low brained with constrcuted arguments not working in the real life and they were only coonstructed to push this feature because some developers are bored and fear this maybe happen also to users if they do not change permanently things which are working fine yes i know, now i get a reply about politness - but face the truth! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 8:30 AM, Reindl Harald h.rei...@thelounge.net 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 are not all yet in. But the stateless feature handles a lot of it already. this is a additional reason why the /usrmove is completly Harald, it is one step in a process. I am very happy and thankful that Fedora is working in this direction. Now, it's time for me to step aside from this thread. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
/usrmove and path ordering
-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 /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPOocVAAoJEEr1VKujapN6ndoH/An7h4cw1Y0nUVttHIZ9dKiY UAbpn5hkpCErWQhEfpP+Rxbcdn2x4yy2fVhSz8Q9KLP9cdolfyxNsV5eNojq3opt 6FZkClD/7Xz0UR1e5KpJye1+ogkiKEHLUheRgtJmH1ouXQ1heWTko4haYbmzmNl5 0qqpBDJVPBb4+rBhZxHMjwafbF3wkNt+gErb7rkJkOPzq7i5PpiXFkLSknhj8M/X M4QijxIfnoN/WqyT+NkMfxUX/6KxFO+ZNnBDaXVQfBx3ywgLapbSmOHE/7sToiEZ FO8/Qdu+7YtKHHqh26GHsOEBWUZfwXTMe4NOOlZCRRiV/rPCxLutX68x7M7VkP8= =w41Y -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 and /usr/sbin before /sbin. Right now $(which a-binary) would report that all /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
-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, 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 /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... Ah, great. They are still used in Koji (even for Rawhide) but it's probably just a matter of time then. - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPOoufAAoJEEr1VKujapN60mgH/j5MaVuaqZKdqYuwyGA2/7tX pl+KOJDBWdaAhFjz9MFNYlN5CtEVt+pGIEf0MuuDe9VKgNk+GNisThTI+9qtYVXz MEjdl0FdGuPCIhPHnLGJwRqW4KPsByn2BVAzMJP+jCwSjYqwS3qN7/3LQPkZILaq 0MaApVxOUZYT2E1XpJqy7ad5fPj5TAorU9hn5+VJC+pgg8R0XNO5rU77CXMHI+MK vwf7weHu3OOhlnqiXB4FH7DrtDla6hemlww78AuCE3tRCQ0QjaYjeoqpATBni9O6 qT6MvfTgR1LmvzD+j6rhpM+ndmjDhJ1AtFOku0zwFSDddtDft2AtMzOIxm2DxJ4= =14en -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 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 /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin as well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 /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 /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin as well. Also, has the default linker path (in glibc, I guess?) been adjusted? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
- 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 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 /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin as well. You are right, setup update fixed only /sbin locations... /bin has to be done on glibc and shells side. Sorry for confusion... Greetings, Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 state? Because dropping these dirs from the search paths is merely an optimization, not a requirement. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
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 affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
