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: > 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. The problem is that designating a source imply that Debian provide a minimal set of garanties for the source. - if the .deb includes a flatpack, we need to provide a way to build it from source for license reason, at which point we are back to square one. - if the .deb download the flatpack at installation time, then how do we make sure the file stays available during the lifetime of the release at the time the user actually installs it ? - what about security updates ? If you need examples of the problems that happen, look at the flashplugin-nonfree package. Cheers, -- Bill. Imagine a large red swirl here.
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
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. My primary concern is to prevent disruption to users. That's a philosophical issue far beyond the two packages of mine that are currently impacted. If these software centers were able to smartly suggest a different source for a software package in a situation where that package was removed from the source the user was currently using, that would certainly address my concerns. It would make life easier for me as well because then I would just outright remove my problem packages from Debian without fear of negatively impacting users. (I've been on the receiving end of that impact a couple times and it was unpleasant to suddenly realize that a system upgrade made me lose a piece of software that I routinely use.) -Olek
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
On Mon, Feb 10, 2020 at 05:48:42AM -0500, Sam Hartman wrote: > I'm not really sure that policy is the best place for this sort of > discouragement though. Why not? Policy discourages loads of things. If we agree that it's not the right thing to do (I'm inclined to agree with that), then we should totally document that in policy. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#950994: Discourage package in contrib to install the real program via another package manager
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 think that unless there is a reason for such an installer, they should be discouraged. But I can see good reasons. I'm not really sure that policy is the best place for this sort of discouragement though.
Bug#950994: Discourage package in contrib to install the real program via another package manager
On 2/9/20 8:43 AM, Shengjing Zhu wrote: > Source: debian-policy > Severity: wishlist > > 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. Since I'm the maintainer of those two packages, I figured I'd chime in here. :) > 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. 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. -Olek signature.asc Description: OpenPGP digital signature
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-
