Re: multiple versions Re: python-cyvcf2 test failures (Was: python-pybedtools: fixing the failing tests)
Hi Steffen,
On Mon, Jul 23, 2018 at 02:16:42PM +0200, Steffen Möller wrote:
> > I disagree with providing two versions for very low popcon packages. We
> > will end up in a maintenance hell if we try to put our really low
> > manpower on two *minor* versions of some software just because upstream
> > decides to break compatibility and some downstreams do not follow. I'd
> > prefer if we could fix downstream (python-bedtools) to support the
> > latest interface since this is sustainable in the longer term.
>
> We need to think of something, though. Somehow the notion of a stable
> API seems to be losing grounds. And folks like conda don't even notice
> this much - they just go and change a >= to = in their dependencies.
>
> Our standpoint was that we as a community help identify such breakages
> and help fixing them. But for bedtools we have semantic differences in
> its tables that are unfixable. And this will get worse as an increasing
> number of communities are adoping conda build scripts.
I tand to disagree. I do not consider it a valid argument to go the
easy road and give up educating upstream only because others do so as
well. As far as my experience goes most upstreams (at least those that
"existed" in a way that they responded) were open for technical
suggestions from Debian. I percive Debian Med as bridge between
upstream developers and users and this bridge goes to both sides. We do
not only deliver what upstream provides but we also tell them if their
code might cause trouble under certain use cases.
> We also had this with Java a lot and strictly versioned maven
> dependencies. This seems to have improved over time, but from what I
> perceive, it is still not perfect.
Sure. But this is *because* people were working on it and did not
gave up.
> There are other pressing things on my end for the remainder of this
> month. But I think I am still for introducing a second package. Please
> discuss this at DebConf. Maybe someone finds a way to include
> snapshot.debian.org in build processes,
I can assure you that nobody considers snapshot.debian.org a good
candidate for the build process.
> which basically breaks the
> concept of releases but lets us specify environments dynamically - just
> like conda is doing it.
I'd prefer if we would package conda and let users decide whether they
want to go with plain Debian packages or rather with conda
installations. I'm not yet convinced that conda is competing with what
we are providing. It provides a solution for use cases we can not cover
but there are other use cases where Debian packages are the better
answer than conda.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: