Bug#950994: Discourage package in contrib to install the real program via another package manager

2020-02-14 Thread Shengjing Zhu
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

2020-02-14 Thread Shengjing Zhu
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