On Thu, Dec 7, 2017 at 4:31 AM, Oliver Grawert <ogra@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.
again, not a "blanket" solution but an alternative ...
> >
> > >
> > > 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.
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@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
