recursive dependency with github.com/coreos/pkg

[mwhudson]

Hi,

Currently github.com/coreos/pkg/capnslog/journald_formatter imports github.com/coreos/go-systemd/journal, but github.com/coreos/go-systemd/journal and github.com/coreos/go-systemd/sdjournal/journal import github.com/coreos/pkg/dlopen. This is a pain for distro developers: we want to package both github.com/coreos/go-systemd and github.com/coreos/pkg but cycles in the dependency graph are a pain. In this case it looks as if .../pkg/dlopen could move to ../go-systemd but I've no idea if that would really be appropriate.

Splitting things out into separate repos would also always be a fix for this.

Cheers,
mwh

[lucab]

Hi and thanks for the report! Sorry for the dependency loop, I think we can easily manage to break it. However I'm not convinced about moving dlopen to go-systemd, as we (do or may) use dlopen in other places too.

Alternative suggestions:

• Break dlopen in its own separate go-dlopen project
• Break capnlog in its own separate go-capnlog project. There is some discussion ongoing to completely drop capnlog capnslog: deprecation notice pkg#57

@mwhudson opinions on those? In both case I think this discussion should be moved to coreos/pkg tracker, can you please move this dicussion there (or I'll do later)?

Side question: different distros have different policies, are you looking into a specific one?

[mwhudson]

Thanks for the quick response. I've filed coreos/pkg#73 now.

[mwhudson]

Bah, please excuse the spam.