|
|
Subscribe / Log in / New account

Debian discusses vendoring—again

Debian discusses vendoring—again

Posted Jan 13, 2021 9:25 UTC (Wed) by Karellen (subscriber, #67644)
Parent article: Debian discusses vendoring—again

I'm talking about packaging xyz 1.3.1 and 2.0.1, as separate xyz-1 and xyz-2 packages, and allowing the use of both in build dependencies. Then, a package using xyz-1 can work with upstream to migrate to xyz-2, and when we have no more packages in the archive using xyz-1 we can drop it.

It seems odd to me if this hasn't been part of the discussion already. Debian already includes packages for gtk-2, gtk-3 and gtk-4, and qt-4, qt-5 and qt-6 as two very prominent examples of parallel semver major releases, but I know I've seen quite a few other similar smaller examples browsing the package lists. Why would that not be an obvious part of the background for everyone involved?


to post comments

Debian discusses vendoring—again

Posted Jan 13, 2021 13:27 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

The big difference is in timing. GTK+ and QT+ have different versions, sure. But upstream supports these. There are parallel releases — but these are supposed to be parallel-installed.

And the whole discussion is about things like Jenkins where two versions are not supposed to be installed and where about three months (but we don't know how much, exactly) is supposed to be called “Long Term Support” (I wish I was joking, I'm not).

Debian discusses vendoring—again

Posted Jan 15, 2021 6:25 UTC (Fri) by murukesh (subscriber, #97031) [Link] (1 responses)

According to https://www.jenkins.io/download/lts/, they seem to have settled on a 12-week cadence. But considering they say the normal release cadence is weekly (!), 12 weeks seems like a very long time in comparison (comparing with, say, Ubuntu, where the ratio of LTS/normal support duration is 60 months/9 months ~ 6.66).

Debian discusses vendoring—again

Posted Jan 22, 2021 2:48 UTC (Fri) by khim (subscriber, #9252) [Link]

You couldn't release anything weekly. There are just not enough time to find and fix problems in any new features.

The most you can promise if you “release” weekly is “hey, it passed our automatic testing and therefore we hope it's not completely broken”. That's not a release. 20 years ago it would be called “alpha version” (not even “beta”: beta is supposed to be tested by some testing teams before release, not just pass CI bot). I'm not even sure that thing which they call “an LTS release” can be compared to “normal” stable release of XX century software which you can actually trust.

The really strange result of all that activity is the fact that as “release cadence” shortens the actual, tangible, changes become less and less frequent. But resource consumption and number of bugs skyrockets. Simply because nobody can understand how the whole thing is supposed to work — and the amount of band-aids applied to pile of existing band-aids which ensure that the whole thing doesn't crash immediately upon startup is just endlessly grows.

As Hoare (original inventor of Quicksort) said: there are two ways of constructing a software design — one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

What we are looking on in that pile of weekly “releases” and pile of “containers” is the end result of application of 2nd principle.

Debian discusses vendoring—again

Posted Jan 13, 2021 21:50 UTC (Wed) by plugwash (subscriber, #29694) [Link]

"quite a few" yes, but still a small minority of the total packages. Packaging multiple major versions of the same software is neither explicitly prohibited nor explicitly permitted. In practice it is strongly frowned-upon, though it does happen.

If you just package a new version every time upstream pushes semver and don't go back and clean things up you can quickly end up with a whole pile of versions of a whole pile of libraries.

Some people advocate that it's better to package a new version first in parallel, then go back and port software, rather than trying to do the transition in one bang. The fear is without the carrot of getting the new version of your pet project into testing and/or the stick of having your pet project removed from testing, the work will never get done and the version proliferation will become a reality.

And it gets even worse if the upstream community doesn't see version proliferation or proliferation of tiny unmaintained packages as problems.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds