[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What can Debian do to provide complex applications to its users?



Le vendredi 16 février 2018 à 16:11 +0100, Raphael Hertzog a écrit :
> Hello everybody,
> 
> the fact that I had to request the removal of dolibarr from Debian
> makes
> me sad (see below for the reasons) and I believe that we should be
> able
> to do better to provide complex applications to our end users.

I feel your pain too and agree with your assessment.

> Dolibarr is not alone:
> 
> - while gitlab is packaged in Debian, its packaging took years and
> the
>   result is brittle because it can break in many ways whenever one
> the 
>   dozens of dependencies gets updated to some new upstream version
>   (BTW salsa.debian.org does not use the official package)
> 
> - I have the Debian packaging of distro-tracker (the code behind
>   tracker.debian.org) available in the git repository for years
>   but I never released it into Debian because it embeds a few
> javascript
>   libraries (bootstrap, jquery) and I don't want to validate that
>   it does work with the versions currently in Debian
> 
> I'm sure we are missing lots of good applications due to our
> requirements.
> What can we do to avoid this?

The problem also comes from the disconnect between current software
development practices: relying on libraries pinned to a specific
version, or with unstable APIs, or vendored to the code base, and the
ideal proned by Debian: a centralized repository of dependencies which
all applications should be built with.

The situation is particularly visible with the Javascript ecosystem,
but similar problems are appearing in the Python and Ruby world. 

> I don't have any definite answers although there are ideas to
> explore:
> 
> - we could relax our requirements and have a way to document the
>   limitations of those packages (wrt our usual policies)

In particular for non-compiled libraries kept private to the
application. These should represent a lower threat vector than say,
multiple vendored copies of openssl or zlib.

> - we could ship those applications not as .deb but as container
>   and let them have their own lifecycle

Not sure what you mean, but I trust you on that.

> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?

Or do our best to support alternative means of installing software such
as docker, snap or flatpak.   

> Cheers,
> 
> On Fri, 16 Feb 2018, Raphaël Hertzog wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > I'm the usual sponsor of dolibarr in Debian. The maintainer (and
> > upstream author) Eldy Destailleur announced me a few weeks ago that
> > he
> > will no longer be maintaining Dolibarr within Debian because it was
> > too much of a pain to respect all the Debian requirements.
> > 
> > He explained to me that Dolibarr relies on 15 javascripts libraries
> > (some of them
> > are dependencies of the libraries that Dolibarr are using in the
> > first
> > place) and 5 PHP libraries.
> > 
> > Debian's requirement to provide a non-minified copy of the
> > javascript is
> > really hard to meet for him because often the projects are only
> > providing
> > the sources under the form a github link (and not under the form of
> > a non-minified javascript that we could put next to the minified
> > file to
> > please lintian). He would have to spend a lot of times with the
> > different
> > upstreams to get them to provide the non-minified file in a form
> > that is
> > suitable for Debian. It's even likely that his requests would be
> > dismissed
> > by multiple upstream authors leaving him in the inconvenient
> > position of
> > having to remove features to be able to ship a policy-compliant
> > Debian
> > package.
> > 
> > The requirement to use packaged versions of all the libraries is
> > also
> > problematic. More often that not the version used by Dolibarr will
> > not
> > match the version currently available in Debian and it's always a
> > risk
> > to use a different version. Sometimes it will work just fine,
> > sometimes it
> > will break.
> > 
> > Given all those constraints, he decided to stop trying to maintain
> > Dolibarr in Debian and the Dolibarr project will only provide an
> > unofficial .deb embedding all the libraries that they need.
> > 
> > I doubt anyone else is willing to maintain Dolibarr in Debian and
> > I'm
> > thus requesting the package to be removed. Users are better served
> > by the upstream unofficial package rather than by Debian's outdated
> > package (it's outdated due to the difficulty of updating it in a
> > policy-compliant way).
> > 
> > I would hope that we could find a way to get the best of both
> > worlds
> > but right now it seems that we don't have a good solution for that
> > kind
> > of web application.
> > 
> > Thank you.
> > 
> 
> 


Reply to: