But really, I don't understand the complaint. Writing explicit dependencies literally what Puppet -- or any other config management system -- is about. Puppet cannot possibly know what your intent is. So you have to tell it. Just like you have to tell the OP's system. It's simple enough.

Having used Puppet for a few years, my biggest complaint is that it's not quite modular enough. For example, in one system I have a way of declaring an "app". An app may have some dependencies (Postgres, Memcached), settings, users, etc. I have two choices, I think; either have one large, monolithic define allowing me to instantiate the app from a bunch of config:

    apps::app {
      "someapp":
        environment => 'production',
        uses_unicorn => true,
        db_name => 'someapp_production',
        db_user => 'someapp',
        memcached_servers => [...],
        # etc.

    apps::app {
      "someapp":
        environment => 'production';
    }
    apps::memcached_config {
      "someapp":
        servers => [...];
    }
    apps::db_config {
      "someapp":
        host => ...,
        db_name => ...,
        db_user => ...;
    }
    apps::unicorn_config {
      "someapp":
        ;
    }

Puppet is very modular, but it's a bit awkward when it comes to this level of modularity -- or I haven't found a better way.

Other tools just execute manifests top to bottom, which is a much less error-prone approach.

I agree that finding the right abstraction level for modules (and for reuse) is not well solved.

Then assign classes like: class{'ntp':}-> class{'ssh':}-> class{'other_stuff':}

problem solved?

But this is Prolog and ordering in Prolog is deterministic. Clause goals are proven in order. When there are multiple clauses with the same predicate, they are executed in order. If this weren't the case extra-logical facilities such as cuts wouldn't work in Prolog