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
