Recommending people Snap things in response to valid packaging problems (WAS: Re: need help resolving python-setuptools backport fail)

[Matt Welland]

On Thu, Dec 7, 2017 at 4:31 AM, Oliver Grawert <ogra at ubuntu.com> wrote:

> hi,
> Am Mittwoch, den 06.12.2017, 17:43 -0600 schrieb Simon Quigley:
>
> [snip]


> >
> > I guess maybe I'm not a fan of the fact that now apparently the
> > standard
> > solution to "I'm having this interesting packaging problem, any
> > ideas?"
> > is now "have you tried packaging the thing in this completely
> > different
> > packaging format that oversimplifies things?" because it doesn't
> > really
> > help the people who want to learn and work on actual packaging (as
> > opposed to putting everything in a yaml file) and it completely
> > avoids
> > the actual problem at hand.
>
> not sure how one can "oversimplify" packaging (and i'm saying that as
> core developer with 15 years of debian packaging experience). Packaging
> is a necessary evil to deliver (and update) software to your users in a
> safe and sane way and some package formats make reaching this goal
> complex and others do not. I dont see how saving time with this task
> and thus being able to in the end bring more software to your users
> with the same amount of work is bad in any way.
>
> nobody said this is a standard or should become one though, but it is a
> valid alternative to have the very latest SW available, and definitely
> a viable alternative to doing a backport going 8 releases backwards
> (especially when you serve *all users* of *all releases* with this one
> single package in the end).
>
> I also dont see how "fixing the actual problem at hand" on a package
> system level is wrong here (vs fixing the same thing by doing a lot of
> manual work), unless your goal is to entertain yourself by doing it vs
> focusing on the end result "get that stuff to your users, so they can
> use it" ... after all the result is the same for them (a working
> offlineimap with the latest version in their preferred release)
>
> >
> > But maybe this is just me who has noticed that this is an increasing
> > trend in responses to emails like this...
> >
> is it a bad thing to have alternatives ?
>

I'd like to state some possibly obvious things here. Apologies for
perpetuating this thread but I think this is an important discussion.

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.

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.

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
> > > > 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?
> > > >
> > > 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 ...
> > "I know how to package in this one format that just involves throwing
> > it
> > all into a yaml file and it will automagically figure out all the
> > deps
> > for you" -- doesn't really solve the problem, but as I said above,
> > seems
> > to be the "blanket solution" nowadays.
>
> again, not a "blanket" solution but an alternative ...
> seems we seem to have different goals in our work on ubuntu (which is
> totally fine btw)...
>
> ...but again, i was just pointing out a possible alternative and not
> asking anyone to do it like this ...
>
> ciao
>         oli
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20171207/1de70020/attachment-0001.html>