Open paulhey opened 2 years ago
pop-upgrade does not touch third party sources, besides removing them on upgrade.
so here's what I'm seeing:
root in apt/sources.list.d on main
❯ git status
On branch main
nothing to commit, working tree clean
root in apt/sources.list.d on main
❯ pop-upgrade recovery upgrade from-release
checking if pop-upgrade requires an update
Recovery event: fetching recovery files
Recovery upgrade status: recovery partition refueled and ready to go
root in apt/sources.list.d on main [!] took 23s
❯ git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: adoptopenjdk.list
modified: byobu-ubuntu-ppa-bionic.list
modified: microsoft-prod.list
modified: mongodb-org-5.0.list
modified: mono-official-stable.list
modified: saltstack.list
modified: wireshark-dev-ubuntu-stable-focal.list
no changes added to commit (use "git add" and/or "git commit -a")
Is there something else that pop-upgrade calls that might be doing this?
https://github.com/pop-os/upgrade/blob/master/src/repair/packaging.rs#L18
Sources are fixed to ensure no conflicts with the running release.
So pop-upgrade
modifies the list files directly via the repair
function. In the microsoft-prod example above, the "repaired" file is not even correct and causes apt update
to error out. Would it not make more sense to at least temporarily disable the third party list files (via repolib, eg. apt-manage modify microsoft-prod --disable
) and notify the user that the repo(s) is(/were) disabled? Would it make sense to have a switch for pop-upgrade
to prevent it from calling repair?
# EG:
The following third party repos were disabled:
microsoft-prod
If this is unintended, please verify the URL and re-enable with:
`apt-manage modify <repo-name> --enable`
So when calling pop-upgrade recovery upgrade from-release
, it looks like repair gets called here:
https://github.com/pop-os/upgrade/blob/0dd0b76489bc0d1278621880c5a28bdcdec2f984/src/recovery/mod.rs#L72
Yes, but you should not use focal repositories on impish.
That's not helpful. I don't have an alternative as some vendors don't provide packages for non-LTS Ubuntu distros and I don't blame them. I guess I'll have to suffer this process until the next LTS is available and vendors release updated repos to match.
Look into Flatpak and using Docker for dev containers. Or even nix-env
Thanks for the suggestions. I use Flatpak where possible, followed by deb packages (and then snaps). In my case, deb package repos are all I have to work with.
Look into Flatpak and using Docker for dev containers. Or even nix-env
I had a similar problem. Flatpak if posible for everything if not Docker. RIght now im trying to move everything i can to docker as it makes it super easy to mantain.
DEB packages depends on installed libs. If a DEB depends on an older lib not present on current release you will have the same problem. Just happened to a client trying to install MEGA desktop client on Pop Beta.
So this issue is difficult to search for to see if there's a solution. here's my system:
Whenever I run
pop-upgrade
it breaks several of the third party repositories I have in my/etc/sources.list.d/
by renaming the distro fromfocal
toimpish
. Some of these repos only provide packages for LTS distros. (eg. https://packages.microsoft.com/, https://repo.mongodb.org/apt/ubuntu)here's the diff on the microsoft one:
I have temporarily created a git repo for this folder to work around reverting the specific repo files to a known working state (eg.
git reset HEAD --hard
). Are there any suggestions or recommendations at this point? Should pop-upgrade test the changes to the *.list files after making them? should it leave LTS repos alone? Or is this a repolib issue?Thanks!