Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils
Just one more thing On Sun, Oct 14, 2018 at 01:13:28AM +0200, Andreas Henriksson wrote: > On Sat, Oct 13, 2018 at 06:28:03PM -0400, Muammar El Khatib wrote: > > Is that what you meant? If that is correct, then I think that the > > package `mkchromecast` does not have to be provided at all. If you go with "the -common way" then yes... eventually! You will still need to provide an upgrade path for current users, so for atleast 1 debian release you would need to have a transitional mkchromecast package that simply depends on mkchromecast-common. This is another reason I would not go with "the -common way", but rather the alternative in the patch (or the third option). Regards, Andreas Henriksson
Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils
On Sat, Oct 13, 2018 at 06:28:03PM -0400, Muammar El Khatib wrote:
> On Fri, Oct 12, 2018 at 4:13 AM Andreas Henriksson wrote:
[...]
> > 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.
[...]
> 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/.
Yes (except -common packages usually don't ship /usr/bin things).
This basically means renaming the current mkchromecast package
to mkchromecast-common.
> 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`.
Yes, isn't that what you already expect them to do?
>
> 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.
As I tried to explain before, but probably confused you with by
mentioning two different ways in the same mail. I think "the -common
way" (discussed above) is not the preferred way though. The alternative
would be like the attached patch does (untested, but hopefully it should
show my thinking). It implements the way I quoted at the top of this
mail from my previous mail and has the following advantages over "the
-common way":
- you can install from either direction. Doing 'apt install
mkchromecast' gives the uninformed user a nice setup, and the
picky informed people can still do 'apt install mkchromecast-alsa'
to get a particular set.
- this is much more in line with how most other packages does it.
- you don't have to go through NEW queue because of renamed packages.
Having said that, I think there's a third option here as well. Since
mkchromecast-* seems to just be meta-packages that for many users seems
to add more confusion than they help. The third option would thus simply
be to get rid off all -* packages (removing packages doesn't need NEW
either) and simply listing all pulseaudio/alsa pieces under Recommends
on the main (and only) mkchromecast binary package. That way people get
all choices and functionality by default, but people who want a slimmer
install and are informed can skip installing the pieces they don't want.
This would actually be probably the most in line with debian policy and
how most other packages does it.
Hope this helps.
Regards,
Andreas Henriksson
diff -uriNp mkchromecast-0.3.8.1/debian/control mkchromecast-0.3.8.1.patched/debian/control
--- mkchromecast-0.3.8.1/debian/control 2017-12-24 15:29:49.0 +0100
+++ mkchromecast-0.3.8.1.patched/debian/control 2018-10-14 01:00:07.010435210 +0200
@@ -27,11 +27,10 @@ Depends: ${python3:Depends},
opus-tools,
youtube-dl,
nodejs,
- gir1.2-notify-0.7
+ gir1.2-notify-0.7,
+ mkchromecast-pulseaudio | mkchromecast-alsa | mkchromecast-gstreamer
Suggests: libav-tools,
- ffmpeg,
- mkchromecast-pulseaudio,
- mkchromecast-alsa
+ ffmpeg
Description: Cast your Linux audio or video to your Google Cast devices
It is written in Python, and it streams via node.js, ffmpeg, or avconv.
mkchromecast is capable of using lossy and lossless audio formats provided
@@ -57,8 +56,8 @@ Depends: ${python3:Depends},
${misc:Depends},
pavucontrol,
pulseaudio-utils,
- pulseaudio,
- mkchromecast
+ pulseaudio
+Recommends: mkchromecast
Description: Pulseaudio dependencies to cast with mkchromecast
This dependency package contains an informational list of packages which are
considered essential for using mkchromecast together with pulseaudio sound
@@ -71,8 +70,8 @@ Depends: ${python3:Depends},
alsa-utils,
alsa-tools,
kmod,
- ffmpeg,
- mkchromecast
+ ffmpeg
+Recommends: mkchromecast
Description: ALSA dependencies to cast with mkchromecast
This dependency package contains an informational list of packages which are
considered essential for using mkchromecast together with
Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils
Hi, On Fri, Oct 12, 2018 at 4:13 AM Andreas Henriksson 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 > > 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 ,''`. : :' : `. `' `-
Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils
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 > 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
Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils
Hi Muammar, > The package suggests mkchromecast-pulseaudio: > > > Taking a closer look at the description of Mkchromecast there is the > following text: > > ``` > mkchromecast can cast using either pulseaudio or ALSA. The respective > dependencies can be pulled by mkchromecast-pulseaudio and > mkchromecast-alsa dependency packages respectively. For more > information, please read the README.Debian file shipped in this package. > ``` > > I think this bug should be closed. Let me know what you think. You are right. It looks quite solid. I must admit I filed the bug in a hurry after being annoyed when I did not get it to work immediately - but rather quickly found out what single piece was missing (without looking at the documentation). Then I spent the time afterwards enjoying the music via my big loudspeakers over mkchromecast - and forgot completely about the bug. Feel free to close the bug. Thanks. and sorry for wasting your time.. :( Best regards Ruben
Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils
Hi Ruben, On Sat, Sep 29, 2018 at 3:33 AM Ruben Undheim wrote: > > Package: mkchromecast > Version: 0.3.8.1-1 > Severity: normal > > Dear Maintainer, > > I get an error saying 'pactl' cannot be found when > starting. Solved it by installing pulseaudio-utils. > The package suggests mkchromecast-pulseaudio: ``` Package: mkchromecast-pulseaudio Version: 0.3.8.1-1 State: not installed Priority: optional Section: sound Maintainer: Muammar El Khatib Architecture: all Uncompressed Size: 16.4 k Depends: pavucontrol, pulseaudio-utils, pulseaudio, mkchromecast Description: Pulseaudio dependencies to cast with mkchromecast This dependency package contains an informational list of packages which are considered essential for using mkchromecast together with pulseaudio sound server. This package also depends on the packages on that list. Homepage: http://mkchromecast.com Tags: admin::hardware, role::plugin, works-with::audio ``` Taking a closer look at the description of Mkchromecast there is the following text: ``` mkchromecast can cast using either pulseaudio or ALSA. The respective dependencies can be pulled by mkchromecast-pulseaudio and mkchromecast-alsa dependency packages respectively. For more information, please read the README.Debian file shipped in this package. ``` I think this bug should be closed. Let me know what you think. Best, -- Muammar El Khatib. Linux user: 403107. GPG Key = 71246E4A. http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `-
Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils
Package: mkchromecast Version: 0.3.8.1-1 Severity: normal Dear Maintainer, I get an error saying 'pactl' cannot be found when starting. Solved it by installing pulseaudio-utils. Best regards Ruben -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages mkchromecast depends on: ii flac 1.3.2-3 ii gir1.2-notify-0.7 0.7.7-3 ii lame 3.100-2+b1 ii nodejs8.11.2~dfsg-1 ii opus-tools0.1.10-1 ii python3 3.6.6-1 ii python3-flask 1.0.2-3 ii python3-psutil5.4.6-1+b1 ii python3-pychromecast 2.3.0-1 ii python3-pyqt5 5.11.2+dfsg-1+b1 ii sox 14.4.2-3 ii vorbis-tools 1.4.0-10.1 ii youtube-dl2018.09.10-1 mkchromecast recommends no packages. Versions of packages mkchromecast suggests: ii ffmpeg 7:4.0.2-2 pn libav-tools pn mkchromecast-alsa pn mkchromecast-pulseaudio -- no debconf information
