Prevent do-release-upgrade from disabling 3rd party repos

[Sam Varshavchik]

Tommy Trussell writes:

>    This is not going to work, because I need the local repository pulled
>    into 
>    the upgrade in order to update the custom packages from jammy to noble,
>    as 
>    part of the upgrade. Otherwise I believe the upgrade will either fail due
>    to 
>    unresolved dependencies, or my custom packages will get uninstalled. Or, 
>    even worse, they'll get replaced by Ubuntu-packaged debs, which will
>    create 
>    a mess. I need to include my local repo in the upgrade, in order to
>    properly 
>    update everything.
>
>
>
> Can you set up a clone of the system and TRY it?
>
>
> Consider what needs to happen from the Ubuntu perspective -- 
>
>
> When you upgrade package A there may be no changes needed to data files etc.  
> Maybe this is true for 90% of packages.

Since I'm building the packages, and I'm the one who wrote those packages,  
I'm fairly certain that I know how the upgrade process would work.

> Standard Ubuntu Package B, however, requires that a change in the format of  
> the /etc files, maybe do something to data in another place, so on and so  
> forth, so there's an upgrade script that needs to run. Ubuntu staff and  
> volunteers have very carefully tested this WITH STOCK UBUNTU SYSTEMS.

All of this is taken care of. I'm both the upstream and the builder.

> You're saying your special applications require special handling, and Ubuntu  
> has no idea how to handle them. That makes perfect sense!

That's ok. Because I know how to handle them, and plain, garden-variety,  
package upgrade will work.

> Even if it isn't, it's probably EASIEST to back up everything, install Ubuntu  
> from scratch, then install your modified software and restore your data.

I see no reason why Debian-based distributions cannot handle what Fedora- 
based distribution easily handle, with the same software. I do the same  
thing on Fedora – use mock to build source on the new release, plug in the  
local repository and just run dnf system-upgrade. Mission accomplished.

My issue is with using Ubuntu tools to effect the same: just include  
packages from an extra repository into a regular system upgrade, to a new  
point release.

>    I can see that at the point where it issues this warning, do-release-
>    upgrade 
>    already fudged /etc/apt/sources.list, and commented out my entry in 
>    /etc/apt/sources.list.d, and I am very tempted to manually reenable it. 
>    However, I'd like to know the right way to do this.
>
>
>
> I suggest this might very well work, though as they say, if it breaks at  
> least you still have all the pieces! 

Yes, I know how pick up the pieces if it breaks. However do-release-upgrade  
refused to even consider this upgrade.

After poking it, I finally was able to find additional logging in  
/var/log/dist-upgrade, and this is the problem:

2024-08-30 14:45:00,668 DEBUG verifySourcesListEntry: deb [arch=amd64] file:///home/mrsam/.aptly/public noble main
2024-08-30 14:45:00,668 DEBUG url_downloadable: file:///home/mrsam/.aptly/public/dists/noble/Release
2024-08-30 14:45:00,668 DEBUG s='file' n=” p='/home/mrsam/.aptly/public/dists/noble/Release' q=” f=”
2024-08-30 14:45:00,668 DEBUG entry '# deb [arch=amd64] file:///home/mrsam/.aptly/public jammy main' was disabled (no Release file)

For some reason do-release-upgrade was convinced that I had "no release  
file".

I sure do. I'm looking right at that file. It's there. Together with it's  
PGP signature.

At this point, an old memory surfaced, from years ago when I first attempted  
the same upgrade, that time to jammy, that I'm now upgrading from.

I just remembered that back then I figured out that do-release-upgrade  
chokes on file: URLs. So:

# deb [arch=amd64] file:///home/mrsam/.aptly/public jammy main
deb [arch=amd64] http://ripper/aptly jammy main

And this time do-release-upgrade managed made it past this point. That was  
its major malfunction. It does not understand file: URLs, something that apt  
has no issues with. But instead of producing a clear "Yo! I don't grok  
file:" error message, the end result in an obscure error message that does  
absolutely nothing to describe the real issue.

Oy vey, I wasted several days on this. I really don't think it was too much  
to ask for a plain error, just tell me you don't grok file: URLs,  
explicitly, instead of forcing me into this wild goose chase.

BTW, I canceled the upgrade anyway. It was going to do something I did not  
like, so I need to make more tweaks to my pbuilder scaffolding, then try  
again…


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20240830/46f5f72f/attachment.sig>