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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Shengjing Zhu-3
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-----

Reply | Threaded
Open this post in threaded view
|

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

Olek Wojnar-9

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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-3
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.

Reply | Threaded
Open this post in threaded view
|

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

Wouter Verhelst
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

Reply | Threaded
Open this post in threaded view
|

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

Shengjing Zhu-3
In reply to this post by Sam Hartman-3
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.

Reply | Threaded
Open this post in threaded view
|

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

Shengjing Zhu-3
In reply to this post by Olek Wojnar-9
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

Reply | Threaded
Open this post in threaded view
|

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

Olek Wojnar-9
Hi,

Sorry for the slow reply, life has been interesting recently...

On Fri, Feb 14, 2020 at 2:26 PM Shengjing Zhu <[hidden email]> wrote:
<snip>

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
Reply | Threaded
Open this post in threaded view
|

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

Shengjing Zhu-3
On Fri, Apr 3, 2020 at 11:31 AM Olek Wojnar <[hidden email]> wrote:

>
> Hi,
>
> Sorry for the slow reply, life has been interesting recently...
>
> On Fri, Feb 14, 2020 at 2:26 PM Shengjing Zhu <[hidden email]> wrote:
>>
>> <snip>
>>
>> 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

Reply | Threaded
Open this post in threaded view
|

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

Bill Allombert-4
In reply to this post by Olek Wojnar-9
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. <[hidden email]>

Imagine a large red swirl here.