Thursday, 7 December 2017

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


Hello Mark and Ogra,

First of all I would like to explain myself a bit more; I was just
simply frustrated after reading the original thread because I have had
increasing interactions with people in the Ubuntu community who have
just said "Snap the thing" or similar in response to people asking about
their Ubuntu deb packaging problems, and have led them through a path
completely different from the one from which they began. I have further
responses inline, but when Mark said:

> Your characterization is simply incorrect, and I hope you'll agree after
> a cup of tea and a walk :)

While tea is not really my thing, a good 9 hours of sleep and a nice cup
of coffee does wonders. ;)

And yes, while my characterization was a bit of a hyperbole, I still
observe this sort of thing going on. (Further below I explain why in my
opinion this is not a productive thing).

On 12/07/2017 05:31 AM, Oliver Grawert wrote:
> with some experience (and knowledge of the right tools) it isnt a
> "several hours experience" really ...

To be fair here, the same can be said when building a deb package.

> i remember my first deb package taking several *days* to get right, i'd
> say several hours for a new packaging format you are not familiar with
> is a pretty good outcome :)

In my opinion if someone has already started learning Debian-based
packaging and has at least basic knowledge of the anatomy (if not more
knowledge) then learning a new format just to solve their problem is
throwing them a bit of a curveball (when the documentation in my
experience does not accurately describe how to do a lot of things quite
yet), no? (Not to say it doesn't have advantages in certain cases, but
in this particular case it might not be beneficial.)

<snip />

> 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 I think turning to the mailing list with problems that have been
encountered and asking for help (when I'm fully aware Walter has
knowledge of Snap packages' existence) proves that he would like to
actually figure out the problem. In fact, he did say:

> This may be a bit ambitious given the python depends, but I'm taking
> it as a good learning experience.

(I answered the remaining part of the email as part of my response to
Mark below)

On 12/07/2017 06:42 AM, Mark Shuttleworth wrote:
<snip />

> First, we continue to do a ton of SRUs and backporting in the deb world.

While I do certainly see the SRUs, I have seen much less backports being
processed than have actually been filed (in fact, right after my email,
I saw processing of a couple bugs pointed out to me by other developers,
which is a good step in the right direction). I don't personally think
this is a result of Snap packages existing but rather as a result of the
people in ~ubuntu-backports not having an interest in processing
backports as much anymore.

Please, do correct me if I'm wrong here.

> Second, the *actual* problem you stated is that you want to make a newer
> version of offlineimap available to Ubuntu users. And Ogra (who has been
> an Ubuntu developer as long as I have been an Ubuntu user ;))
> recommended that you try snaps, which solve that problem perfectly. They
> solve that problem for 14.04, 16.04, and current 18.04 too, which is
> very elegant.>
> The deb world is wonderful. But backporting trees of Python dependencies
> is risky for a LOT of software and a LOT of users. Sometimes it's the
> right answer, hopefully you would agree that in this case, perhaps
> digging into that snap is worth considering. Another community member
> has already made one for you to try.

To be 100% clear, this was Walter Lapchynski looking to solve his
problem, not me. ;)

In this particular case though, as I said above, his goal seems to me to
be less of "I want to get this out to lots of users quickly" and more of
"I want to learn how to fix this problem to further my packaging
knowledge" and while I feel both circumstances have their own respective
paths to follow, in this case figuring out the answer to the problem he
is having would help him reach his end goal more appropriately.

> The great thing about Ubuntu is that it consists of lots of people who
> have *different* interests, and occasionally they can teach each other
> stuff. You've helped LOTS of people learn stuff too :)

I agree, and I think that this is a major reason of why I continue to
contribute to Ubuntu; people can work on what they would like to work
on, depending on their interests and goals. I don't think Snaps are a
bad thing, I just think that they have a time and place (much like deb
packages, and other "universal" packaging formats like flatpak and
appimage, each has their advantages and disadvantages, and none of them
are complete replacements for all the rest), one that hasn't really
reached the point where I as a contributor use them enough or have
enough of a need for them to warrant contributions from my end. One
point that I would like to make is that my end goal in contributing to
this discussion and starting a new subthread (if you will) is because I
want to help Walter and anyone else that may come across this list
archive in the future solve a packaging problem and to have a discussion
about how packaging problems like this could be solved in the future.

Just my two cents, speaking for myself.

Thanks for both of your time,
Simon Quigley
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4