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

[Pirate Praveen]

On Sun, Jul 12, 2020 at 18:05, Thorsten Glaser <t.glaser at tarent.de> 
wrote:
> On Sun, 12 Jul 2020, Pirate Praveen wrote:
> 
>>  > 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).
> 
> That’s no excuse to not set these two settings. You definitely ought
> to set NotAutomatic: yes because otherwise, merely *adding* the repo
> can cause packages from fasttrack to be installed that the user did
> not explicitly select to install from there. And 
> ButAutomaticUpgrades: yes
> is needed to be able to upgrade once NotAutomatic: yes is set.
> 
> Until this is done, fasttrack is to be classified as dangerous.
> 

This change is now active.

aptitude -t buster-backports install gitlab/buster-fasttrack

is still not able to solve it on first try, but it is better than 
earlier.

The following packages have unmet dependencies:
 gitlab : Depends: ruby (>= 1:2.7~) but 1:2.5.1 is to be installed
          Depends: rubygems-integration (>= 1.17.1~) but 1.11+deb10u1 
is to be installed
          Conflicts: libruby2.5 but 2.5.5-3+deb10u2 is to be installed
The following actions will resolve these dependencies:

     Keep the following packages at their current version:
1)     gitlab [Not Installed]

and in second attempt,


      Keep the following packages at their current version:
61)     libruby2.5 [Not Installed]
62)     ruby-json [Not Installed]
63)     ruby2.5 [Not Installed]
64)     ruby2.5-dev [Not Installed]

I think rebuilding ruby-json with ruby 2.7 might fix it.

>>  > 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.
> 
> […]
> 
>>  Because you did not add buster-backports suite.
> 
> Erm… I did add buster-backports, the official one.
> 
> You absolutely cannot have a thing called buster-backports on the
> fasttrack server because that’s too easily confused with the
> official one.
> 
> Erk. I don’t even want to continue looking at fasttrack now.

This will be done after figuring out the best way to do the renaming.