Am Dienstag, den 05.12.2017, 10:29 -0800 schrieb Walter Lapchynski:
> On Tue, 05 Dec 2017 10:27:14 +0100 Oliver Grawert <email@example.com>
> > 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
> 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
> response to backports, I guess it explains why there are so many
> unanswered backport requests against Trusty. Maybe if there were
> desktop systems completely maintained through snaps only, this might
> a reasonable approach, but we don't have that.
it is not a common response to backports but i guess it should become
the common response over time for non-system applications. since snaps
are a build-once-run everywhere solution that does not depend on the
underlying release. admittedly you would have to apt-get install snapd
when running on trusty, but snaps run identical on all ubuntu releases
that have snapd installed.
along with that i noticed there is actually an offlineimap snap in
progress sitting in the candidate channel today that you should be able
to install via "sudo snap install --candidate offlineimap" on all
releases and distros that have snapd available (details are at:
https://github.com/snapcrafters/offlineimap and i bet popey would
appreciate help and testing)
> Furthermore, that this really does not answer the original question.
Yes, if the original question was about a python backport exercise it
definitely does not answer this and i'm sorry if i de-railed the track
with the answer ... it is just that creating a 20 line snapcraft.yaml
file to backport something is a lot easier than having to manage a
whole python stack :)
> find it quite possible that the question will still stand regardless
> 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?
not for doing a backport of the whole python stack as deb packages,
no... i disagree that this is no build level issue though, given that
snapcraft will simply care for getting the right deps for you without
any additional backport work when packaging offlineimap with it though
anyway, sorry for hijacking the thread, i was just trying to point out
an easy way here to achieve the same goal ...