need help resolving python-setuptools backport fail

Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

need help resolving python-setuptools backport fail

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. I've been working my way up the depends tree
with `backportpackage` with great luck, at least up until I ran into
python-setuptools. Looking at the [sbuild output][1], it seems that all
the right depends (including several main python packages, including 2.7
and 3) are pulled in.

Looking on GitHub (and apparently ignoring the dates because they seem
to be at conflict; perhaps a data transfer issue), it looks like the
string "Cannot build setuptools without metadata. Run bootstrap.py" is
certainly in the [version][2] I'm trying to build. This supposedly
fixes an [issue][3] when building in a clean environment from a repo
checkout. Considering the watch file points at PyPi rather than GitHub,
I'm going to assume that latter detail is not applicable. It does seem
like we're using the sdist. But yet, the same behavior.

So perhaps bootstrapping is something that must be done first? I'm
hoping one of you with experience packaging setuptools may be able to
help. Otherwise I'll go try barking up the maintainer's tree.

Thanks in advance,

[1]: https://paste.ubuntu.com/26059403/
[2]: https://github.com/pypa/setuptools/blob/v33.1.1/setup.py#L19
[3]: https://github.com/pypa/setuptools/issues/659
--
       @wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: need help resolving python-setuptools backport fail

Oliver Grawert
hi,
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 ?

ciao
        oli
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: need help resolving python-setuptools backport fail

Walter Lapchynski
In reply to this post by Walter Lapchynski
On Tue, 05 Dec 2017 10:27:14 +0100 Oliver Grawert <[hidden email]>
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.

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?

--
       @wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: need help resolving python-setuptools backport fail

Oliver Grawert
hi,
Am Dienstag, den 05.12.2017, 10:29 -0800 schrieb Walter Lapchynski:

> On Tue, 05 Dec 2017 10:27:14 +0100 Oliver Grawert <[hidden email]>
> 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.
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 :)

> 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 ...

ciao
        oli


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: need help resolving python-setuptools backport fail

Mark Shuttleworth-2
On 12/06/2017 05:32 AM, Oliver Grawert wrote:

> hi,
> Am Dienstag, den 05.12.2017, 10:29 -0800 schrieb Walter Lapchynski:
>> On Tue, 05 Dec 2017 10:27:14 +0100 Oliver Grawert <[hidden email]>
>> said:
>>> 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 show up in the software store, and we'll do the same for CLI users
so that snaps are nicely discoverable.


>> Snaps are nice and all, but they don't seem really
>> ideal as a backport solution for this very reason.


Let's work together to fix that issue, so that we don't have to do as
much work backporting everything with complex chains of dependencies.

>>  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.

We're moving to just that approach, for just this very reason. We want
to enable everyone to get the latest version of LibreOffice the day it
is available upstream, not wait to upgrade their whole world, or deal
with insane dependency trees. The dependency mechanism is fantastic for
the OS release itself, but it becomes impossible to then accommodate
change over time in the app layer. Hence the list of backport requests.
Let's fix that. If you want to focus on discoverability for snaps, that
would be great.


> 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)

Yes I bet he would, though he seems to be up to date with 7.1.4 in the
edge channel :)

Mark


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Simon Quigley-2
In reply to this post by Oliver Grawert
Hey,

On 12/06/2017 04:32 AM, Oliver Grawert wrote:
> 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 :)

The difference here is that in order to figure out that 20 line yaml
file it often takes a fair bit of time (several hours in my experience),
to get all the isolation bits etc. working properly.

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.

But maybe this is just me who has noticed that this is an increasing
trend in responses to emails like this...

>> 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.

Just my two cents, my opinions are my own.

Thanks,
--
Simon Quigley
[hidden email]
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Oliver Grawert
hi,
Am Mittwoch, den 06.12.2017, 17:43 -0600 schrieb Simon Quigley:

> Hey,
>
> On 12/06/2017 04:32 AM, Oliver Grawert wrote:
> >
> > 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 :)
> The difference here is that in order to figure out that 20 line yaml
> file it often takes a fair bit of time (several hours in my
> experience),
> to get all the isolation bits etc. working properly.
with some experience (and knowledge of the right tools) it isnt a
"several hours experience" really ... (snappy-debug.security scanlog
<packagename> will for example exactly tell you which interfaces to
enable, that cuts down the setup of "isolation bits" to a 5min task)

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 :) 

>
> 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
> > > 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
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mark Shuttleworth-2
In reply to this post by Simon Quigley-2
On 12/06/2017 05:43 PM, Simon Quigley wrote:
> 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.

Well, hold on.

First, we continue to do a ton of SRUs and backporting in the deb world.
Your characterization is simply incorrect, and I hope you'll agree after
a cup of tea and a walk :)

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.

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 :)

Mark


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Matt Welland
In reply to this post by Oliver Grawert
On Thu, Dec 7, 2017 at 4:31 AM, Oliver Grawert <[hidden email]> 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
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Simon Quigley-2
In reply to this post by Mark Shuttleworth-2
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
[hidden email]
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Oliver Grawert
In reply to this post by Matt Welland
hi,
Am Donnerstag, den 07.12.2017, 09:08 -0700 schrieb Matt Welland:

> On Thu, Dec 7, 2017 at 4:31 AM, Oliver Grawert <[hidden email]>
> 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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Oliver Grawert
hi,
Am Freitag, den 08.12.2017, 11:50 +0100 schrieb Oliver Grawert:

> 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.

this pargraph came out a little softer than it should be actually ... 

with "trust" above i mean indeed "ultimate trust" ... 100% full root
access to all of your OS.

debhelper runs as root and so do all preinst/postinst maintainer
scripts of any deb you install.

ciao
        oli


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: need help resolving python-setuptools backport fail

Steve Langasek-6
In reply to this post by Walter Lapchynski
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 <[hidden email]>
> 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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment