On Wed, Jan 29, 2014 at 1:13 PM, Richard Purdie <[email protected]> wrote: > On Wed, 2014-01-29 at 12:59 +0000, Laszlo Papp wrote: >> On Wed, Jan 29, 2014 at 12:52 PM, Richard Purdie >> <[email protected]> wrote: >> > On Wed, 2014-01-29 at 12:32 +0000, Laszlo Papp wrote: > >> > By having a default of /home/root/ we can catch software that has issues >> > with relocation of that. >> >> I am not sure what you mean. Could you please elaborate? > > As you mention, "/root" is more standard. It therefore becomes hard to > spot software that assumes this rather than using the directory we > configure it to if the default is also /root. > > By having a slightly more unusual default choice, we quickly find the > software that doesn't adapt to our variable.
You seem to be referring to testing rather than forcing a test case for the software, and hence majority. There are two better alternatives IMHO to address this: a) QA team defines such a test case. b) In addition to a), you would get reports from users who set it to /home/root if there are issues. Although, I am certainly questioning that if more than 10-20% was setting it to "/home/root" at all, or even much less. Daniel in the CC also wrote an issue on IRC that it could lead to a non-loginable system if the /home does not get mounted which would better not be mandatory without setting it explicitly IMHO. >> > Having the writeable user data in one directory like this is useful >> for several classes of embedded style devices. >> >> Could you please provide any examples? > > One that springs to mind is the Sharp Zaurus series of PDAs have > separate /home partitions in flash. You can reflash a new rootfs without > overwriting the user config data. I addressed this issue in my initial email, but I will reiterate this concern with two solutions: a) You can do package update rather than reflashing. b) Even if a) does not work, as written in my initial email, you can have a /root partition. Still, the fact that you can only mention one use here, is somewhat also self-explanatory that it is not the majority. >> > So to be honest I don't see a pressing reason to change this. >> >> I do, because the earlier it is done, the fewer users that may have >> incompatible changes. As the time goes ahead, more and more users will >> stick to it as "default". I believe this means those who do not care >> about proper Unix separation. > > Its been like this for years and seems to work perfectly fine for > people. I do not see it perfectly fine that if the majority of the people get the extra work rather than the minority. I saw this several times now in the history that it was done manually on the end-users side, and since it is not just me, I thought I would bring this topic up. I would rather prefer to ease the end users' work wherever it is possible. > You can configure it just fine. As I said previously, I see no > pressing reason to change it. As written before, you could configure the other way around, too. The question boils down to that: who should configure it on its own? * The person who tries to follow the unix philosophy and the generic behavior on most of the Unix systems out there? * The person who follows some rare use case? My opinion is the former. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
