Dropbox is looking for deprecated package

Like in many other cases, seems nobody can say anything (from Dropbox side)!

I think, It's stupid decision to conclude that dropbox isn't installed if there is some problem running it (even erroneously detected problem). I mean the code near line 1440 in 'dropbox':

    if not start_dropbox():
        if not should_install:
            console_print()
            console_print("The Dropbox daemon is not installed!")
            console_print("Run \"dropbox start -i\" to install the daemon")
            return

        # install dropbox!!!
        try:
            download()
        except:
            traceback.print_exc()

From other view point, in 'start_dropbox' function, near line 760 in the same file:

        # in seconds
        interval = 0.5
        wait_for = 60
        for _ in range(int(wait_for / interval)):
            if is_dropbox_running():
                return True
            # back off from connect for a while
            time.sleep(interval)

        return False

Can be seen that decision for successful running depends on 'is_dropbox_running' function result. This function result from other side depends on matching pid, set on time in '~/.dropbox/dropbox.pid', as can be seen near line 140 in the same file:

def is_dropbox_running():
    pidfile = os.path.expanduser("~/.dropbox/dropbox.pid")

    try:
        with open(pidfile, "r") as f:
            pid = int(f.read())
        with open("/proc/%d/cmdline" % pid, "r") as f:
            cmdline = f.read().lower()
    except:
        cmdline = ""

    return "dropbox" in cmdline

And here is the place where the problem comes from. On heavy loaded system, during initial login, many other services can query for processor time and disk access simultaneously, together with Dropbox! Additionally open web browser left from previous session, carrying few tenths of pages, and other similar applications can query together system resources. In such a situation setting correct pid can take some time. During all this time 'is_dropbox_running' function will think that the Dropbox is NOT running, even while it really runs (or at least going to, without totally finished initialization still)! The 'start_dropbox' function assumes the same, next some timeout. And finally, as result, follows stupid conclusion that Dropbox is not installed (erroneous)! The same erroneous conclusion (and initiating install action) could be triggered by virtually any runtime error in the daemon, during initialization (even incident one, non related in any way to the installation process)!

The easiest and fastest workaround is timeout set to be increased (for example doubled). Of course such action is definitely not a solution because there is no exact answer "How much?"! Real solution would be the chain of assumptions break. Wich mean restructuring the code and write it without assumption that something is, if there could be opposite situation (even when such situation seems not likely). If You don't follow above rule lead to error prone code (error - including race conditions and not only).

Again, please forward this to your technical team. I hope it will help improving Your code.