need help resolving python-setuptools backport fail

[Steve Langasek]

Hi Walter,

On Tue, Dec 05, 2017 at 10:29:29AM -0800, Walter Lapchynski wrote:
> On Tue, 05 Dec 2017 10:27:14 +0100 Oliver Grawert <ogra at ubuntu.com>
> said:
> > Am Donnerstag, den 30.11.2017, 09:25 -0800 schrieb Walter Lapchynski:
> >> I'm currently trying to backport offlineimap from zesty to trusty.
> >> This
> >> may be a bit ambitious given the python depends, but I'm taking it as
> >> a
> >> good learning experience.
> > did you consider a snap ?

> No, I did not. What guarantee would there be that a user with Trusty
> would be able to even find it? If they have trusty-backports installed
> and there's standard packaging, they'll automagically get the update.
> Not so with snaps. Snaps are nice and all, but they don't seem really
> ideal as a backport solution for this very reason. If this is a common
> response to backports, I guess it explains why there are so many
> unanswered backport requests against Trusty. Maybe if there were whole
> desktop systems completely maintained through snaps only, this might be
> a reasonable approach, but we don't have that.

Suite: trusty-backports
NotAutomatic: yes
ButAutomaticUpgrades: yes

 (http://archive.ubuntu.com/ubuntu/dists/trusty-backports/Release)

You certainly would not automatically get the update to a version of the
package simply as a result of having trusty-backports installed.  This is a
difference by design between SRUs and the backports repository.

In that respect, I think that snaps are at least as good a solution as
backports for this kind of thing.  Backports also has the problem that
you only have two choices for the update track: you can stick with the main
Ubuntu archive and receive only security updates and SRUs, or you can switch
to backports and then get automatically updated to whatever version has been
backported most recently - even if that backport channel switches to
backporting from a newer release and causes integration problems.  With
snaps, you can provide tracks for however many stable versions as might be
appropriate for the package.

It's true that the user would need to have snapd installed, which it isn't
by default on trusty, in order to know the package is available.  (NB: you
also have to be using the hwe kernel to use snapd on trusty, as the GA
kernel is too old.)  But -backports is also opt-in, so I wouldn't view that
as a major advantage either.

> Furthermore, that this really does not answer the original question. I
> find it quite possible that the question will still stand regardless of
> whether or not I considered a snap. This is a build-level issue, from
> what I can tell, not necessarily a matter of the packaging framework.
> That said, do you have any relevant advice?

Well, except that you don't have to backport the stack package-by-package
onto trusty in the case of a snap, you could simply use all of the
already-successfully-built .debs from zesty as needed; so I would expect
this to be a non-issue for a snap.

As for solving this in a .deb backport, I'm afraid I don't have any insight.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20171209/615e9b17/attachment.sig>