Hi, Chiming in here because I'd like to just suggest an alternative that might be more in line with how other packages are layed out and thus how users might expect things to work.
On Thu, Oct 11, 2018 at 04:24:16PM -0400, Muammar El Khatib wrote: > On Sat, Sep 29, 2018 at 3:33 AM Ruben Undheim > <ruben.undh...@beebeetle.com> wrote: [...] > > I get an error saying 'pactl' cannot be found when > > starting. Solved it by installing pulseaudio-utils. > > > > The package suggests mkchromecast-pulseaudio: [...] I think I understand how you layed out the package. You expect the user to pick a particular special version that suits their needs from mkchromecast-* and install that. Then that pulls in the common (mkchromecast) package. If a package has the bulk of the program, but users are not expected to directly install it but rather have it pulled in via a dependency then usually the package name gets a -common postfix, ie. in your current layout you could have named mkchromecast mkchromecast-common instead. Going back a bit and looking at the bigger picture again I find your current layout not how packages in debian normally are layed out. Normally I find that the main package (mkchromecast here) instead has alternative dependency on the different backends, eg. mkchromecast would: Depends: mkchromecast-pulseaudio | mkchromecast-alsa | mkchromecast-gstreamer (Or in which ever order you prefer, listing the recommended and best supported backend as the first alternative.) (And to avoid circular dependencies, the mkchromecast-* package would have to drop or demote the Dependency on mkchromecast to a Recommends.) This way the users can just pull the package named after the program and end up having the recommeded backend pulled in for them. With this package layout you avoid ever having an uninformed user ending up with installing a package and having it 'not working'. If they install mkchromecast they get the recommended backend with it. If they install a particular mkchromecast-* the recommends will pull in the mkchromecast package. (And if they disable installing recommends then they are expected to pay attention or they get to keep all their broken pieces. eg. apt install mkchromecast mkchromecast-gstreamer would given them the non-default backend without pulling in the recommended/first alternative dependency.) While I find your package layout okish (albeit not in line with other stuff in debian), I think someone could technically still argue that the 'mkchromecast' binary package is RC-buggy since installing it in a clean environment leaves it missing needed functionality to operate. Thus I didn't take the liberty of downgrading the severity on this bug, but please note that the autoremoval tracker has your package targeted for removal on Oct 28 so some action on this bug report before then would be nice. Hope this helps. Regards, Andreas Henriksson
