Enable or disable test repo before dist-upgrade?

Message
Author
User avatar
asqwerth
Developer
Posts: 7211
Joined: Sun May 27, 2007 5:37 am

Re: Enable or disable test repo before dist-upgrade?

#11 Post by asqwerth »

Test Repo is not Testing, by the way.

MX Test Repo is MX's repo of newer/backported/compiled packages - not originating from Debian Stable - that have not been fully tested. They were packaged by MX's Packaging Team to be compatible with Debian Stable.


Debian Testing is a Debian repo where packages for the NEXT version of Debian Stable are being tested. It's a different base from current Debian Stable so is not compatible with Debian Stable.
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400

User avatar
seaken64
Posts: 819
Joined: Wed Jan 02, 2019 2:43 pm

Re: Enable or disable test repo before dist-upgrade?

#12 Post by seaken64 »

asqwerth wrote: Mon Jan 21, 2019 12:56 pm Test Repo is not Testing, by the way.

MX Test Repo is MX's repo of newer/backported/compiled packages - not originating from Debian Stable - that have not been fully tested. They were packaged by MX's Packaging Team to be compatible with Debian Stable.


Debian Testing is a Debian repo where packages for the NEXT version of Debian Stable are being tested. It's a different base from current Debian Stable so is not compatible with Debian Stable.
Well, I suppose it's a good thing I only had that MX Test repo enabled and not the Debian Testing. To be honest I think I have kept that antiX or MX test repo enabled in the past. But like I said I've never had any bad effects so far. But maybe that's because I use a limited set of apps. But from now on I will be more careful and I will not leave any repos enabled beyond the defaults.

I'm understanding how it works now. And I did re-read the manuals, and help files for the Repo Manager and MX Package Installer. I understand more of it now after the tips you all have shared in these forum threads. But I must say that the manual is not very clear for a newbie and the warnings do not clearly spell out what is going to happen with dist-upgrade or how to actually enable/disable the source repo without using MXPI. Of course, MXPI is the solution to this but I don't always have that (I use a lot of older versions and antiX).

In a previous thread it was suggested that maybe we enter all this stuff into the wiki. There is some info on the wiki, and the FAQ, and we have the warnings and help files from MXPI, but I think it would be helpful for newbies to have a specific set of instructions available in the wiki. The warnings can have a link to the explanatory wiki to help the user understand the whole process and the relationships between repos and dist-upgrade.

[BTW, there is no warning pop-up on the Repo Manager on either MX or antiX like there is on the MXPI]

Maybe something like this:
"WARNING! This option can open your system to incompatibilities and instability and break your system. Please read and understand this linked wiki page before proceeding. Use with care!"
Then, after the link is opened it can start with something like this:
"These instructions are for users of antiX or early versions of MX. If you are using MX-17 or later we suggest you just use MX Package Installer and avoid the potential trouble of forgetting to disable an alternate repo. MXPI handles the entire enable/disable process for you for all alternative repos on it’s lists."
Then a full wiki article with a summary similar to this:
"So, here are the basic steps you should use to temporarily enable an alternative repo from which you want to install a software package:

Use the Repo Manager, or your preferred package manager, to enable the alternative repo. “Apply” the change and run an “update”.

“Install” your software package.

After the install routine is finished, “disable” the alternative repo by unclicking it again and choose to “Apply”. The next time an update is run the alternative repo will not be active.

If you run an “upgrade” or “dist-upgrade”, or if you allow the apt-notifier routine to run, make sure you have already followed the above procedure and “disabled” any alternative repos."
Seaken64
MX21-64 XFCE & W11 on Lenovo 330S LT. MX21-KDE & MX21-XFCE on Live USB.
MX18-64 & W7, Fedora on HP Core2 DT
MX21-32 XFCE w/ MX-Fluxbox on P4HT DT w/ antiX21, SUSE Tumbleweed, Q4OS, WXP
antiX21 on Compaq PIII 1 Ghz DT, w/ Debian, MX18FB, W2K

User avatar
dphn
Posts: 126
Joined: Sun Nov 25, 2018 7:26 am

Re: Enable or disable test repo before dist-upgrade?

#13 Post by dphn »

when you want to do it manually, enable the test repo in /etc/apt/sources.list.d/mx.list. (Remove the # in the line with the test-repo source) and do ONLY sudo apt-get update and sudo apt-get install <your package> and then set the # before the test-repo line again to disable it after install.

Of course, it's easier to use MXPI. But this for understanding, what MXPI do when you install software from test-repos. :wink:
for those with an eye for the finer details...

User avatar
Stevo
Developer
Posts: 12774
Joined: Fri Dec 15, 2006 8:07 pm

Re: Enable or disable test repo before dist-upgrade?

#14 Post by Stevo »

For the vast majority of packages, you can update them all from the test repo without dependency problems. Whether a newer version will remove or break some feature in the program is a separate issue.

I would estimate we get a dependency problem in the test repo only a few times a year, and we fix them quickly, unlike some problems that Debian backports have had. The last one we had was just a few days ago, though, when my Mesa 18.2.8 update made it impossible to install libgtk-3-dev GTK+ 3 development files, but that was only a problem for a day or so until I fixed it.

Some packages that are security or other fixes go straight to main after packager testing, such Firefox or Pale Moon, or a zfs-dkms I just sent up to fix builds on our 4.19 kernel. Simple packages that don't affect anything else, like Neofetch 6.0 that I also just sent up, are also sent up if they work fine for the packagers.

Post Reply

Return to “General”