**** BEGIN LOGGING AT Fri Dec 12 02:59:59 2014 Dec 12 15:04:06 koen: about antisocial layers; what's the difference in SRC_URI_append_mymachine += "file://fstab" vs just mangling FILESPATHEXTRA and putting fstab in files/mymachine/fstab subdir? Dec 12 15:10:00 mago_: if you use SRC_URI_append_mymachine, only machine will use fstab. if you do SRC_URI_append , you require all machines to have it. no? Dec 12 15:10:46 ndec: yeah, but if i put it in a mymachine-subfolder, bitbake will only include that if MACHINE=mymachine, right? Dec 12 15:11:06 no. to include the file it needs to be in SRC_URI Dec 12 15:11:16 if i specify file://fstab, it'll look in files/, files/${MACHINE}/ etc Dec 12 15:11:48 well, file://fstab is in SRC_URI in both cases (sorry, a little bit out of context) Dec 12 15:11:53 right. but if you only have the file in files/mymachine, then it will fail for all other machines Dec 12 15:12:02 ah. Dec 12 15:12:43 then that's ok. if fstab is always there, and you want to customize for a specific machine, then you can put the custom version in files/mymachine Dec 12 15:13:36 so the scenario is: base-files has a fstab, and puts file://fstab in SRC_URI. In a bbappend we want to override this fstab, so the comparison im making is if we put SRC_URI_append_mymachine += "file://fstab" (and then put fstab in files/ subdir to the bbappend), OR if we instead just mangle FILESPATHEXTRA in the append, and simply put the file in files/mymachine/fstab Dec 12 15:13:56 my question is, is there a difference between these two methods? Dec 12 15:14:33 koen was calling the first approach antisocial (the layer might break other layers), where the bbappend uses SRC_URI_append_mymachine Dec 12 15:14:55 SRC_URI_append_mymachine += "file://fstab" is not necessary, since SRC_URI already has fstab. Dec 12 15:15:32 it's necessary if the replacement fstab is placed directly into files-subdir of bbappend Dec 12 15:15:46 (which might be totally wrong, but it works) Dec 12 15:16:35 hmm. i don't think it should be needed. you just need to modify FILESPATHEXTRA to use your layer files folder Dec 12 15:21:50 if you put it in files/fstab, you break other layers, even with the _append_mymachine Dec 12 15:22:40 oh. i didn't realize the other option was files/fstab... Dec 12 15:23:04 I encountered that a few years ago Dec 12 15:23:20 the maintainer insisted it was safe because he used _append_mymachine Dec 12 15:23:23 koen: why does it break by putting files/fstab in my layer? Dec 12 15:24:11 because files/fstab will override fstab for everymachine using the standard fstab Dec 12 15:24:25 bitbake goes "hey look, an fstab in a dir without override!" Dec 12 15:24:35 oh right, since FILESPATHEXTRA prepends? Dec 12 15:24:38 exactly Dec 12 15:24:51 i see. i really need to fix my layer then :) Dec 12 15:24:54 thanks for the input Dec 12 15:28:13 my current favourite example of using overrides the wrong way: Dec 12 15:28:14 EXTRA_OECONF_append_arm = " ${@bb.utils.contains("TUNE_FEATURES", "neon", "--enable-arm-neon=on", "--enable-arm-neon=off" ,d)}" Dec 12 15:28:28 that does the wrong thing on aarch64 Dec 12 15:28:41 and the fix is being held up for unclear reasons Dec 12 15:29:00 something about qemuaarch64 needing to exist before accepting any aarch64 related fixes Dec 12 15:43:08 koen: we both obviously work for bad company.. :/ Dec 12 15:45:44 yeah, l* is considered naughty Dec 12 16:34:46 koen: mago_: I think another way that OVERRIDES are dangerous is that they don't implicitly change PACKAGE_ARCH. Dec 12 16:35:20 E.g. SRC_URI_append_mymachine --> the package will be for the CPU arch... not the machine. Dec 12 16:35:52 So you also need to do something like PACKAGE_ARCH_mymachine := "${MACHINE_ARCH}" Dec 12 16:36:17 Wherease... the files/${MACHINE}/ thing automatically changes the PACKAGE_ARCH for you. Dec 12 19:03:28 vincenet: sounds like you need to speak to the syslog maintainers then; we only compile the applications ;) **** ENDING LOGGING AT Sat Dec 13 02:59:58 2014