Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #190748 > unrolled thread

Weired package policy

Back to article view | Back to linux.debian.user

Contents

  Weired package policy Hans <hans.ullrich@loop.de> - 2018-01-07 16:00 +0100
    Re: Weired package policy Floris <jkfloris@dds.nl> - 2018-01-07 16:30 +0100
      Re: Weired package policy The Wanderer <wanderer@fastmail.fm> - 2018-01-07 16:40 +0100
      Re: Weired package policy Hans <hans.ullrich@loop.de> - 2018-01-07 16:40 +0100
        Re: Weired package policy Roberto C. Sánchez <roberto@debian.org> - 2018-01-07 20:40 +0100
        Re: Weired package policy Mark Fletcher <mark27q1@gmail.com> - 2018-01-08 01:10 +0100
    Re: Weired package policy Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-01-08 04:50 +0100

#190748 — Weired package policy

Hi folks, 

there is a thing, I cannot understand. 

>From time to time, there appear packages, which are in stable for a long time, 
and then suddenly they are in unstable and stable, but NOT in testing.

This is a policy, I do not understand! An actual example is "cqrlog" which 
appears in stable and sid, but not in testing.

For my feeling, I would expect "cqrlog" in testing, too, maybe in the same 
version as in stable, but not fully disappeared. 

Debian's way is not quite clear for me, and IMO I think it not a good idea, to 
let packages silently disappear. At this point, I may be wrong.

Thinking of this let me think of another point, which has never been clear for 
me since years: When I install a new system, and I want to run testing, then 
you MUST also add the repo for stable in the sources.list, otherwise packages 
you might want to use, are missing (due to the policy above).

I searched the manuals for this point, but this was nowhere mentioned. Of 
course, you may say, that this is self-evident, but people might want to have 
the repo small and may think, "hey, if I get testing, then all packages of 
stable will be available as well."

Anyway, maybe someone might enlighten me (and maybe others, too as well) of 
that.

Thank you for all your answers and the great work.

Best

Hans 

 

[toc] | [next] | [standalone]

#190749

Op Sun, 07 Jan 2018 15:58:57 +0100 schreef Hans <hans.ullrich@loop.de>:

> Hi folks,
>
> there is a thing, I cannot understand.
>
>> From time to time, there appear packages, which are in stable for a  
>> long time,
> and then suddenly they are in unstable and stable, but NOT in testing.
>
> This is a policy, I do not understand! An actual example is "cqrlog"  
> which
> appears in stable and sid, but not in testing.
>
> For my feeling, I would expect "cqrlog" in testing, too, maybe in the  
> same
> version as in stable, but not fully disappeared.
>

from: https://tracker.debian.org/pkg/cqrlog

testing migrations
excuses:
Migration status: BLOCKED: Rejected/introduces a regression (please see  
below)
164 days old (needed 5 days)
Updating cqrlog introduces new bugs: #867140

There is difference of opinion about the libssl version. Buster will have  
1.1. Cqrlog depends on 1.0

[toc] | [prev] | [next] | [standalone]

#190750

[Multipart message — attachments visible in raw view] — view raw

On 2018-01-07 at 10:26, Floris wrote:

> Op Sun, 07 Jan 2018 15:58:57 +0100 schreef Hans
> <hans.ullrich@loop.de>:
> 
>> Hi folks,
>> 
>> there is a thing, I cannot understand.
>> 
>>> From time to time, there appear packages, which are in stable
>>> for a long time, and then suddenly they are in unstable and
>>> stable, but NOT in testing.
>> 
>> This is a policy, I do not understand! An actual example is
>> "cqrlog" which appears in stable and sid, but not in testing.
>> 
>> For my feeling, I would expect "cqrlog" in testing, too, maybe in
>> the same version as in stable, but not fully disappeared.
> 
> from: https://tracker.debian.org/pkg/cqrlog
> 
> testing migrations
> excuses:
> Migration status: BLOCKED: Rejected/introduces a regression (please see  
> below)
> 164 days old (needed 5 days)
> Updating cqrlog introduces new bugs: #867140
> 
> There is difference of opinion about the libssl version. Buster will have  
> 1.1. Cqrlog depends on 1.0

I read his objection as being to the policy about what should be done
when a bug bad enough to warrant removing that package version from
testing is identified.

Currently, the policy is that when that happens, the package is removed
from testing.

I read him as saying that the policy *should* be that when such a bug is
identified, the version from stable (or maybe the previous
non-buggy version, from before the upload which introduced the bug)
should be reintroduced into testing.

Unfortunately, this would not work well with the way package version
numbers are handled, and I'm not sure it wouldn't be impractically
unwieldy to implement on the backend in any case.

(Plus the difficulties with dependencies; what happens when the version
which would be reintroduced depends on an older version of another
package, and the newer version is already in testing and does not itself
have such a bug?)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#190751

Am Sonntag, 7. Januar 2018, 16:26:55 CET schrieb Floris:
Hi Floris and all,

maybe my question was not clearly expressed, due to my English. It was not 
aimed to that special package. I would like to know, why packages completely 
disappear, instead of just leaving the last well running version available in 
testing. IMO to fully remove a running version completely in opposite of 
keeping the last good version is in my eyes the worse idea.




> from: https://tracker.debian.org/pkg/cqrlog
> 
> testing migrations
> excuses:
> Migration status: BLOCKED: Rejected/introduces a regression (please see
> below)
> 164 days old (needed 5 days)
> Updating cqrlog introduces new bugs: #867140
> 
> There is difference of opinion about the libssl version. Buster will have
> 1.1. Cqrlog depends on 1.0

[toc] | [prev] | [next] | [standalone]

#190761

On Sun, Jan 07, 2018 at 04:37:49PM +0100, Hans wrote:
> Am Sonntag, 7. Januar 2018, 16:26:55 CET schrieb Floris:
> Hi Floris and all,
> 
> maybe my question was not clearly expressed, due to my English. It was not 
> aimed to that special package. I would like to know, why packages completely 
> disappear, instead of just leaving the last well running version available in 
> testing. IMO to fully remove a running version completely in opposite of 
> keeping the last good version is in my eyes the worse idea.
> 
The package disappears when the version in testing is affected by a
release critical bug which does not get fixed.  If a bug only affects
the unstable/sid version of a package and the package in testing is of a
different version, the package in testing will remain.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#190774

On Sun, Jan 07, 2018 at 04:37:49PM +0100, Hans wrote:
> Am Sonntag, 7. Januar 2018, 16:26:55 CET schrieb Floris:
> Hi Floris and all,
> 
> maybe my question was not clearly expressed, due to my English. It was not 
> aimed to that special package. I would like to know, why packages completely 
> disappear, instead of just leaving the last well running version available in 
> testing. IMO to fully remove a running version completely in opposite of 
> keeping the last good version is in my eyes the worse idea.
> 

One point that has been skirted around in a couple of answers but not 
directly expressed is that putting the old, working version in testing 
is not the right thing to do in some situations if that old version 
cannot be a candidate for inclusion in buster when it is released (that 
is, when it becomes the stable distribution).

Using this package you took as an example, it is not at the moment a 
candidate for inclusion in buster as a release because it depends on a 
version of the SSL libraries that will not be there when buster is 
released (unless something changes). Putting it in testing now would be 
lying, in a way, because that package will not be there when the testing 
distribution becomes the stable distribution. The version already in 
stable is fine because the version of the SSL library it needs is in 
stable.

Why then, you might ask, is the package in sid? Two reasons, I guess : 
one, the package maintainer is clearly engaged in an argument with 
_someone_ about what the right resolution is, but the package isn't 
regarded as evil and isn't being dropped from Debian altogether, on the 
assumption a resolution will eventually be found. Two, the required SSL 
library is in sid but blocked from making the transition to buster, and 
therefore this package cannot make the transition because not all its 
dependencies have.

So in summary this comes about because the package is not _currently_ in 
a state that could be released in a stable buster release, but an 
optimistic assumption that the problem will get solved eventually is 
being made. In the meantime, no claims are being made that buster is 
anywhere near ready for release, so things like this are to be expected.

HTH

Mark

[toc] | [prev] | [next] | [standalone]

#190783

Hans <hans.ullrich@loop.de> writes:
<snip>
> I searched the manuals for this point, but this was nowhere mentioned. Of 
> course, you may say, that this is self-evident, but people might want to have 
> the repo small and may think, "hey, if I get testing, then all packages of 
> stable will be available as well."

As I understand the repository structure, packages in stable are not
necessarily also in testing.  Stable is, as the name implies, packages
that are regarded as good and solid; testing is packages that are
candidates to be upgrades to those in stable.

So, unless you are really running a machine strictly for the purpose of
testing packages, you should have your apt preferences set so that
you'll find packages in stable as that's the standard set of packages,
plus packages in testing so you can stay more current.  In my case, part
of my /etc/apt/preferences is

Package: *
Pin: release a=testing
Pin-Priority: 700

Package: *
Pin: release a=stable
Pin-Priority: 650

in order to capture this intent.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web