Re: Option to allow packages from backports but without forcing it

[Pirate Praveen <praveen@onenetbeyond.org>]

On Sun, Jul 12, 2020 at 18:05, Thorsten Glaser <t.glaser@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.