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

Re: Request to fast track gitlab dependencies



On Mon, 4 Mar 2019, Pirate Praveen wrote:

> 2. Not bother with rails 5 transition, which would have allowed
> keeping gitlab in buster and stretch-backports.

I’ve also held off a transition, so I can provide the older
version in buster/stretch-backports and the newer in
bullseye/buster-backports/stretch-backports-sloppy. The main
idea here is, however, what you can support *in stable*.

This is what Debian releases are about (see §3.1 in the
Developer’s Reference), and what Debian backports are
about (see the Backports rules).

Anything beyond that is out of the scope of these two.
That is not to say it’s not worthwhile, but, as it doesn’t
fit into the stable release cycle, a different place has
to be found for it.

The rule “must be in stable+1” (or backports+1 and stable+2
for sloppy) is not there to annoy you, it’s there to give
users of backports a guideline of what *exactly* they can
expect. Key here is upgradability: backports are supposed
to be TRANSIENT, and one is expected to upgrade a package
from stable-backports to stable+1 without backports. If
the package is not in stable+1 (even if removed later) it
naturally cannot fulfill this and thus will be dropped from
backports as well.

It’s even in the name: backports from the next stable to
the previous one. For a while, new backports from stretch
(then stable) to jessie-backports (then oldstable) were
accepted (until jessie support was dropped).

That you can backport from testing to stable is an exception
to the rule in order to make backports usable. The general
idea here is that, if a package is in testing, chances are
it will end up in the next stable and, therefore, might be
backportable. It is still the uploader’s duty to ensure they
only backport what is likely to end up in the next stable,
and to ask for removal of things that aren’t.

I hope this explanation helps you… if not, it might be beyond.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
	-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel


Reply to: