On 1/10/16 11:13 AM, Matthias Schiffer wrote: (Trimming to just this comment)
> * I stand by my opinion that moving files automatically is a bad idea, > and the FILES issue mentioned in the other thread further backs my point > (besides that issue, I've mentioned relative symlinks and relative paths > in general as problems that can break packages when their files are moved). The issue is simply that MANY packages have a fixed way they install things, and then other actions (do_install) "move" them around to the expected place. We follow that behavior with the fs-perms.txt and "move them around". The only alternative I can think of is to move the fs-perms.txt processing at the beginning of do_install. It could then create the symlinks and directories mentioned. Then the install occurs and the tools would need to know how to deal with it "or fail". (I don't like the or fail..) The other problem though is this would introduce a number of (potentially) empty directories to the a given recipe's install which would kick off the QA warnings. (We'd need to resolve that issue first.) > My proposal would be to change the fs-perms.txt handling to only check > if nothing conflicts with default symlinks, but not to create or move > anything. This is another point I'd like to get more input on. The key here, it can be a lot of additional work (based on experience) to have to go in and change the locations that things are installing components. Things that PROPERLY use gnu autoconf, and other variable systems have an advantage here, but it's not unusual to see references to '/lib' (i.e. the /lib/firmware case), or even to '/sbin' for the non "/usr/sbin" case. We really want this path change, and setup to be seemless for the distro developer. Set up the values in the distro configuration (path variables and fs-perms.txt in some cases) and provide necessary .bbappends or distro specific version of base-files package. Theoretically that SHOULD be all that is required to define the 'filesystem'. --Mark -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
