[talk] classifying BSD init

[Sujit K M]

On Thu, Sep 3, 2015 at 12:53 AM, Patrik Lundin <patrik at sigterm.se> wrote:
> On Mon, Aug 31, 2015 at 07:48:23PM +0530, Sujit K M wrote:
>>
>> Just out of curiosity, what is the difference between one module per project and
>> the present scheme. IMHO there is a lot difference in *BSD as Project. Though
>> This might be true in the case Linux Distros. You have X11 Dbus it is
>> functioning
>> the same way in Linux Distros, But not in the case of BSD.
>>
>
> Currently there exists both modules that handle more than one system
> (like the service module), and modules that are separate based on what
> tool they manage (examples of these are the package management modules
> "apt", "yum" and "openbsd_pkg") which are separate modules but keep a
> similar list of base arguments that they understand.

Are you sure regarding this? All I see in the current implementation is similar
arguments only on the derivative. Like Linux Distros. BSD only.

>
> This means that while I can have a playbook that works on more than one
> operating system if it calls the service module, if I also want to
> install packages I would need to use the "pkg_mgr" fact instead of
> naming a specific module by name.
>
> Just the direction of standardizing on one scheme for handling OS agnostic
> playbooks seems like a good thing to me. Going in the opposite direction
> and trying to merge the package management modules would probably create
> quite a massive module (and lets not forget that while we generally have
> enough bandwidth to go around it might be wasteful to have ansible
> upload large amounts of code that is never run to all managed systems).
>
> Another reason why I like the idea of splitting the module is because
> it separates the logic of deciding "what tool to use" from the actual
> tool logic. This is not that big of a deal for the *BSD classes because
> they are already nicely compartmentalized, but the Linux class is pretty
> complex as it stands right now.

In Ansible It get the OS dependent information every time it upgrades
or installs
a package.