Bug#950994: Discourage package in contrib to install the real program via another package manager
On Fri, Apr 3, 2020 at 11:31 AM Olek Wojnar wrote: > > Hi, > > Sorry for the slow reply, life has been interesting recently... > > On Fri, Feb 14, 2020 at 2:26 PM Shengjing Zhu wrote: >> >> >> >> May not answer you question directly. >> >> There's something called software center. Like discover[1] for KDE plasma, >> gnome-software[2] for GNOME. >> >> Users can install either debian package, or flatpak, or snap apps. >> >> [1] https://tracker.debian.org/pkg/plasma-discover >> [2] https://tracker.debian.org/pkg/gnome-software > > > Ah, yes. That sounds familiar. Maybe this should be the location to implement > that functionality, and implement it upstream. > Maybe such a functionality could be shared and eventually integrated into > aptitude and even apt itself. IMO, this implements in the wrong place. If there are such tools, like discover and gnome-software(they are GUI tools, maybe there's CLI tools which I don't know), it should be consumer of apt/aptitude, snap, and flatpak. Apt itself should be in the same level of snap. It may be a common sense that apt is the entry to install software for a Debian user, but it's also common sense that apt should install a *deb* package. It's really surprise that apt is installing a snap package, via some magics. -- Shengjing Zhu
Bug#950994: Discourage package in contrib to install the real program via another package manager
On Sun, Feb 09, 2020 at 11:47:18PM -0500, Olek Wojnar wrote: > 1) Perhaps surprisingly, I agree in principle that installing from an > external source should not be "encouraged" under normal circumstances. > > 2) However, this illustrates a use case that perhaps has not come up in > the past. As I explained in one of the bug reports against my packages, > the rationale for this was to provide a temporary alternate > functionality for end users while upstream goes through a period of > instability. > > 2a) Ideally, I would have preferred to remove the packages in > question from Debian and have a system that would have presented users > with options for alternate sources of that package. I may try to hack > something together for my packages because I agree with a comment on one > of those bugs that transitioning to an alternate package source should > not be done without explicit user action. > > 2b) In a general sense though, this seems like a mechanism that may > have value beyond these two packages. For example, would it be possible > for maintainers to list alternate sources of a package in a new field in > d/control? Then, if a package must be removed from Debian either > temporarily or permanently, users could be presented with alternate > options for that package. Or if certain users want the bleeding-edge > version they can easily get to it instead of pestering a maintainer to > package something that is not stable enough for Debian. > > 2c) The problem with saying a user could just install from > snap/flatpak/etc is that a user may not know what other options are out > there and may not know if they are authoritative (e.g. many but not all > packages are created by the upstream authors). What I am proposing > (well, more like thinking about at the moment, and looking for feedback) > is a system to create an equivalence between the official Debian package > and the same package in other systems. Does anyone else see value in > such a construct? > > > Another package manager in subject could be snap, flatpak, pip, nix, etc. > > > > [1] https://tracker.debian.org/pkg/cyphesis-cpp > > https://tracker.debian.org/pkg/ember > > [2] https://tracker.debian.org/pkg/snapd > > In summary, as snap/flatpak/etc increase in popularity I think it may be > a good idea to have a formalized method for Debian package maintainers > to designate authoritative equivalent sources for their packages, if > they wish to do so. May not answer you question directly. There's something called software center. Like discover[1] for KDE plasma, gnome-software[2] for GNOME. Users can install either debian package, or flatpak, or snap apps. [1] https://tracker.debian.org/pkg/plasma-discover [2] https://tracker.debian.org/pkg/gnome-software
Bug#950994: Discourage package in contrib to install the real program via another package manager
On Mon, Feb 10, 2020 at 05:48:42AM -0500, Sam Hartman wrote: > I'll note there's another case where this could be valuable. > If there is an installer in contrib, you can express dependencies on the > package being available in Debian. > Depending on how that installer works, you may not be able to express > dependencies on the installed version in Debian. > I agree with this argument when you using the word "installer". We have a lot of installers in contrib. Though a package manager is another kind of "installer", but the situation is different. Says I'm a user of pip. I install a python library using pip, and pin it at version A. Now a package in contrib try to use pip to install this library with version B. This becomes conflict. If another package declares dependencies with this package, the version management becomes mess. So technically this doesn't work, only causing problem for end users.
Bug#950994: Discourage package in contrib to install the real program via another package manager
Source: debian-policy Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I find there are two packages[1] in archive now installing real program using snap[2]. The two packages in main are definitely against policy. But the maintainer is moving them to contrib, which has no problem with current policy. Technically snap is a package manager just like apt/dpkg. I don't think there is any benefit to do this. People want to use snap could just install with snap, no need to call apt. Another package manager in subject could be snap, flatpak, pip, nix, etc. [1] https://tracker.debian.org/pkg/cyphesis-cpp https://tracker.debian.org/pkg/ember [2] https://tracker.debian.org/pkg/snapd - -- Shengjing Zhu -BEGIN PGP SIGNATURE- iIYEARYIAC4WIQTiXc95jUQrjt9HgU3EhUo4GOCwFgUCXkAMaRAcemhzakBkZWJp YW4ub3JnAAoJEMSFSjgY4LAWgxcA/1phh3AZMIcTMQWLVX9Tz4NvGMIcVsJQ56kO NsqGaSISAP41+bj3YJuZpF0lObHcUwQKSo1V7/dN7EyYlgIE1ExZAA== =GVWN -END PGP SIGNATURE-
