hi,
Am Donnerstag, den 07.12.2017, 09:08 -0700 schrieb Matt Welland:
> On Thu, Dec 7, 2017 at 4:31 AM, Oliver Grawert <ogra@ubuntu.com>
> wrote:
> >
> >
> [snip]
>
> > >
> > is it a bad thing to have alternatives ?
>
> Alternatives can be a bad thing if they dilute the effort toward
> solving the problem in a robust way. If the creation of side packages
> using alternative systems subtracts from the effort put toward making
> a deb package then there is something lost from the point of view of
> Ubuntu or Debian. However that is not the only possible outcome. It
> might be that what happens is these interim solutions act as a
> stepping stone to getting good software packaged and that in turn
> leads to deb packages, an all round win.
well, the question here was about backporting an app 8 releases with
backporting a portion of python modules that will, while making
offlineimap work, potentially break other apps using these python
modules. The question was not:
"i want to update offlineimap in bionic and need some help also
updating the python libs"
or:
"i need to SRU offlineimap into ${LTS} to fix an important bug and need
help here to get the debian packaging right"
... it was about a task where snaps are simply better suited by
isolating the shipped python bits from the existing OS libs, by
allowing you to roll with your offlineimap port, by automagically
providing your backport to *all* supported releases and flavours of
ubuntu, by allowing your users to immediately roll back to teh former
version if a new feature after an upgrade is not wanted. a snap is
definitely the better suited alternative for the requested task here.
My answer would have been different if the question was one of the
above, but if your question contains the words "backport" or "PPA",
nowadays "snap" is definitely the better answer over potentially
breaking users installs by pulling in untested dependencies on a system
level.
>
> I don't know which of those possible outcomes is most likely. Perhaps
> folks who have seen instances of one or the other scenario play out
> can comment?
>
> The two main obstacles to packaging that I'm aware of are dependency
> challenges and any complexity related to Debian machinery. I would
> like to package up a project of mine but I have a dependency on IUP
> which is not available as a Debian package. To solve the IUP problem
> I could attempt to debify IUP but others have tried and I'm no
> expert. For my situation the snap approach might work.
there are two other major obstacles ...
- testing in *all* possible scenarios... especially when replacing
something low-level ...
- finding a reviewer, getting your changes reviewed and approved ...
both go completely away with snaps... people that are long enough with
ubuntu might remember that we had an app store for third party apps for
several years ... that used to use debian packages. finding enough
reviewers to make sure these apps are sane and dont break enduser
systems could actually take months and ended in frustration for
everyone involved ... snaps are immediately available after upload and
due to their confinement do not require reviews at all ...
the alternative to that store would be a PPA where you put your trust
into random people you dont know and potentially get untested changes
to your underlying system by some dependencies they provide.
>
> For the long term health of Ubuntu and Debian making it easy to
> migrate from snaps to native packages might be a good move. A
> compiler or wizard that could do most of the tedious stuff would
> help.
>
> Just $0.02 from a wannabe Debian/Ubuntu packager.
>
i personally would like to see us going in the other direction, have a
rock solid underlying deb based system (desktop or server) and use
snaps for enduser applications (from GUI and CLI apps to servers).
allowing app maintainers to independently roll on top of that system
and only maintain one package for all releases (or even multiple
versions side by side if you feel like).
while you are free to compile everything from source, snaps use deb
packages during build and as shipped dependencies by default. using a
different delivery mechanism to your enduser does not mean work on deb
packages can go away, quite the opposite, we rely on a solid and stable
archive for everything in snaps. but at the same time there is now a
proper and safe answer to "why is the latest libreoffice not in trusty
!!!111one" since the libreoffice you packages for the latest release
will just be there ... everywhere ...
we need well maintained debs, that wont change, but we should also take
advantage of new systems where they really provide advantages.
ciao
oli
