Hi, On Fri, Oct 12, 2018 at 4:13 AM Andreas Henriksson <andr...@fatal.se> wrote: > > 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.) >
Your explanation makes lots of sense for me. Just to clarify this layout: 1) mkchromecast-common would contain all needed files to make things functional meaning the python module itself and things in /usr/bin/. 2) There will be other mkchromecast-* packages e.g.: mkchromecast-pulseaudio; mkchromecast-alsa, and mkchromecast-gstreamer and those ones will pull out dependencies to make the package work for each of those audio servers. Basically, instead of doing an `apt install mkchromecast`, users would need to do `apt install mkchromecast-something`. Is that what you meant? If that is correct, then I think that the package `mkchromecast` does not have to be provided at all. I would like just to confirm these things before I go and change the packaging. Thanks for this idea Andreas. Best, -- Muammar El Khatib. Linux user: 403107. GPG Key = 71246E4A. http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `-
