On 8/5/21 6:01 AM, Robert P. J. Day wrote: > > style question here, but i'm perusing an OE/YP (actually wind river, > but effectively the same thing) layer that was handed to me, and i'm > puzzled by how the internally-written systemd-controlled services are > implemented. > > on the one hand, there are reasonable recipes that each represent > some service to be managed by systemd, and they all install their > executables in the right places and so on. however, rather than each > recipe also providing its own service file, there is a totally > separate recipe (call it "systemd-services.bb") which contains under > its files/ directory dozens and dozens of service files for all of > those recipes, and is responsible for installing all of them. > > in short, someone decided that -- for whatever reason -- all of the > systemd service files should be collected all in one place, and > installed en masse. is this ... normal? i would have thought that it's > the responsibility of each recipe to mannage all the content related > to it, and that would of course include the systemd service file to be > installed for it. i don't know the rationale for this, and it strikes > me as a recipe for disaster in trying to keep all these things synced > up. is there some rationale for doing it this way that i'm unaware > of?
For a 'product' (as in, this is only for one implementation and nobody will ever re-use it), I've see this type of thing before. But for anything intended to be re-used, it's simply broken. The service files belong with the recipes providing the services. > and closely related, the same trick was used when defining all the > new users and groups that would own these services. rather than each > service looking after itself, there is a recipe file (call it > "new_users_and_groups.bb") which is hundreds of lines of USERADD_PARAM > and GROUPADD_PARAM lines that define precisely (numerically) all the > new user and group accounts to be associated with all sorts of > services, whereupon i ask the same question -- isn't it more typical > that each service look after its own user and group info? The same is true here, if you are creating a singular product that has a number of defined users and groups, sure you can do it in a recipe like this. But it's not the right way to do it. Users/groups should be associated with their users. If these are just general administrative usages then they COULD be done this way, but more people do it at image generation time. > in this second case, it *might* be that all of these values need to > be hard-coded to be consistent with, i don't know, something else i'm > unaware of, but it still looks strange. If you need to 'adjust' users and groups, you should be using the existing mechanisms, useradd-staticids for instance. --Mark > thoughts? the above actually works for the time being, but it does > seem a but unnatural. > > rday > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154522): https://lists.openembedded.org/g/openembedded-core/message/154522 Mute This Topic: https://lists.openembedded.org/mt/84682032/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
