[Aptitude-devel] Bug#964916: Option to allow packages from backports but without forcing it

[Pirate Praveen]

On Sun, Jul 12, 2020 at 15:23, Thorsten Glaser <t.glaser at tarent.de> 
wrote:
> On Sun, 12 Jul 2020, Pirate Praveen wrote:
> 
>>  But gitlab is not in buster-backports
> 
> Then I don’t understand the problem.

gitlab is in buster-fasttrack, but buster-fasttrack is not self 
contained, it needs buster-backports.

> 
>>  apt/aptitude -t buster-backports  install gitlab/buster-fasttrack 
>> does not work.
> 
> Why?
> 

The same reason as apt/aptitude -t buster-backports install gitlab

> apt-get install gitlab/buster-fasttrack even should work,
> in that case. Depends/Breaks would suffice to make it
> select the right packages from the right suites.
> 

It is not working, hence asking for ideas.

>> For example, ruby-nokogiri is available in buster-backports (built 
>> with
>> ruby 2.5) and buster-fasttrack (built with ruby 2.7).
> 
> Wasn’t the rule that a package may only be in one of them,
> and that it’s only eligible for fasttrack when it’s not in
> backports?
> 

fasttrack's rules are not set in stone, it is evolving based on the 
needs of packages like gitlab. The reason for having to do this is 
because the ruby team does not want to maintain ruby 2.7 in backports 
even though it qualify for backports because it can break packages 
already in stable.

>> # apt policy ruby-nokogiri
>> ruby-nokogiri:
>>   Installed: (none)
>>   Candidate: 1.10.9+dfsg-1+fto10+1
>>   Version table:
>>      1.10.9+dfsg-1+fto10+1 500
>>         500 https://fasttrack.debian.net/debian 
>> buster-fasttrack/main amd64 Packages
>>      1.10.9+dfsg-1~bpo10+1 100
>>         100 https://deb.debian.org/debian buster-backports/main 
>> amd64 Packages
>>      1.10.0+dfsg1-2 500
>>         500 http://deb.debian.org/debian buster/main amd64 Packages
> 
> Well here you also run into the problem that apt prefers
> the newest package.
> 

Why is that a problem? We need the newer version here.

> It also looks like buster-fasttrack is not set up correctly:
> its policy value is 500, not 100 (NotAutomatic: yes and
> ButAutomaticUpgrades: yes).
> 

That is because we don't really expect the packages to be upgradable to 
next stable version (because these packages will not be in any stable 
release).

> Looking at the fasttrack documentation, it also tells users
> to use a buster-backports repository from the fasttrack.debian.net
> site, which is also all kinds of wrong.
> 

Why? There are times when we can't have a package in official backports 
immediately (transitions, backports-new). This is temporary repository. 
These gets removed when they are accepted in official backports.

> But the installability problem has a different cause:
> 
> […]
>           Depends: ruby-faraday (>= 0.17.3~) but 0.15.4-3~bpo10+1 is 
> to be installed
> […]
> $ apt-cache policy ruby-faraday
> ruby-faraday:
>   Installed: (none)
>   Candidate: 0.13.1-2
>   Version table:
>      0.15.4-3~bpo10+1 100
>         100 http://mirror.lan.tarent.de/debian buster-backports/main 
> amd64 Packages
>      0.13.1-2 500
>         500 http://mirror.lan.tarent.de/debian buster/main amd64 
> Packages
>      0.9.2-3 500
>         500 http://mirror.lan.tarent.de/debian stretch/main amd64 
> Packages
> 
> This package simply is not available in the version required.
> 

Because you did not add buster-backports suite.

# apt policy ruby-faraday
ruby-faraday:
  Installed: (none)
  Candidate: 0.13.1-2
  Version table:
     0.17.3-1~bpo10+1 100
        100 https://fasttrack.debian.net/debian buster-backports/main 
amd64 Packages
     0.15.4-3~bpo10+1 100
        100 https://deb.debian.org/debian buster-backports/main amd64 
Packages
     0.13.1-2 500
        500 http://deb.debian.org/debian buster/main amd64 Packages


> bye,
> //mirabilos
> --
> «MyISAM tables -will- get corrupted eventually. This is a fact of 
> life. »
> “mysql is about as much database as ms access” – “MSSQL at 
> least descends
> from a database” “it's a rebranded SyBase” “MySQL however was 
> born from a
> flatfile and went downhill from there” – “at least jetDB 
> doesn’t claim to
> be a database”	(#nosec)    ‣‣‣ Please let MySQL and MariaDB 
> finally die!
>