Alexander Boström <abo <at> root.snowtree.se> writes: > > Please just stop trying to explicitly abuse the system and instead > figure out the cleanest way to solve whatever problem you're trying to > solve. > > /abo > I have already done that - the clean way to solve the OP's problem. But in addition I also tested other possibilities, which would work but are indicative of problems in project's concept and design. Look at this thread once again and you will see that there are at least 3 (THREE) ways people try to respond to OP's problem. Some of them are claimed by the devs to be the "right" ones, or "as intended" to be used. I proposed my own preferred setup, which solves the problem as the OP stated, and to be honest this is also exactly how I would state it and try to solve it if I myself were tasked with it. That is, I selected the way (example 1) to create nfs.service file as representing the group's main service and to create individual service files to represent the group's sub-services to be called as "required", with an option to accommodate other, conditionally needed, group's sub-services or outside-the-group services with the help of other UNIT or SERVICE options in the corresponding unit files. This is a 1:1 setup, reflecting old SysV init. This is what OP wants to have in order to minimize confusion on part of his user base. As I said, this is what I personally would try to achieve too. But, other people propose other solutions within the scope of possibilities, referring to them as "we intended them to be used this way". Well, it is a blessing or a curse. You have to consider your user base and what is the nature of a system setup. It is often prototyping, ad hoc changes/adjusting/experimenting, simplicity of tools, simplicity of concept (system init), time constraints, etc. Also, keep in mind that sysadmins and users are not UNIX/Linux system programmers :-) That's why I posted that sometimes having too much ambiguity and choices (and making the matter worse by suggesting some as preferable more than others, but still offering them all) is a recipe for "mass copulation" and quite probably a sign of bad concept and design. JB -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
