[arch-general] can you only test certain packages?
I'm trying to help with the testing of perl 5.12 but I'd rather not test every package out there. Is it possible to block certain packages from being updated from testing? or only allow certain ones? maybe with a regex? obviously I don't wish to ban them globally. if they make it into a non testing repo I'm fine with it. -- Caleb Cushing http://xenoterracide.blogspot.com
On Thu, May 20, 2010 at 01:29:41PM -0400, Caleb Cushing wrote:
I'm trying to help with the testing of perl 5.12 but I'd rather not test every package out there. Is it possible to block certain packages from being updated from testing? or only allow certain ones? maybe with a regex? obviously I don't wish to ban them globally. if they make it into a non testing repo I'm fine with it.
(This should be a sticky in the forum.) There are exactly two safe options with respect to testing. 1. Update everything from testing. Actually this is a bit overkill. If you just want to update a package Z, it'd be enough to update Z from testing, and also any of its dependencies Y that are also in testing, and also anything in testing that depends on either Z or any of the Ys. That is, Z and all its dependencies, and everything for which any of them are dependencies. Oh yeah, also any dependencies of any of those items, and everything for which any of them are dependencies. And so on. That might fall short of updating *everything* that's available for update from testing. But it will often be many more packages than just Z, and it will often be tedious to trace out all the packages that should be included. So it'd be best to update everything from testing. Sometimes it won't matter; you can just update Z and ignore other available updates and nothing will go wrong. Other times it will matter. So the only safe thing to do, going this way, is to update it all. Especially if you want to *test* package Z, you should do it against its intended environment. 2. The other safe option is to install *none* of the binary updates from testing. Instead, grab the new PKGBUILD for Z from /var/abs/testing/, and makepkg it yourself, against the other packages and libraries you've already got installed. (If you can: that is, if Z doesn't require any newer libraries that are only in testing.) This won't be an ideal test environment for package Z, since it won't be the same binary environment that Z will be deployed in. But for most purposes it should still be pretty useful. And if you can successfully build and install Z, you won't have to worry about library mismatches, like might happen if you just installed the binary Z from testing without also installing dependencies/dependents also in testing. If you do go #2, you should also rebuild any packages that depend on libraries installed by Z, and anything that depends on them, and so on. -- Jim Pryor profjim@jimpryor.net
On Thu, 20 May 2010 23:26:22 +0200, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
On Thu, May 20, 2010 at 01:29:41PM -0400, Caleb Cushing wrote:
I'm trying to help with the testing of perl 5.12 but I'd rather not test every package out there. Is it possible to block certain packages from being updated from testing? or only allow certain ones? maybe with a regex? obviously I don't wish to ban them globally. if they make it into a non testing repo I'm fine with it.
(This should be a sticky in the forum.)
There are exactly two safe options with respect to testing.
1. Update everything from testing. Actually this is a bit overkill. If you just want to update a package Z, it'd be enough to update Z from testing, and also any of its dependencies Y that are also in testing, and also anything in testing that depends on either Z or any of the Ys.
2. The other safe option is to install *none* of the binary updates from testing. Instead, grab the new PKGBUILD for Z from /var/abs/testing/, and makepkg it yourself, against the other packages and libraries you've already got installed.
There is a number 3. 3. Add [testing] and do a pacman -Sy package-you-like. It will install the latest package from testing and its dependencies. Remove [testing] again and you can go on using your non-testing system. I don't know if it is fail-proof but it worked for me with xorg-server (to 1.8). When I'm doing a pacman -Syu it just says that the packages installed are newer and therefore doesn't update these certain packages. -- Jeroen Op 't Eynde - jeroen@xprsyrslf.be - http://xprsyrslf.be To read: http://en.wikipedia.org/wiki/Posting_style#Bottom-posting Steun Jeugdhuis de PUT via Donamail: http://www.donamail.be/default.asp?btnID=iYOviYvW
On Thu, May 20, 2010 at 18:05, Jeroen Op 't Eynde <jeroen@xprsyrslf.be> wrote:
There is a number 3.
3. Add [testing] and do a pacman -Sy package-you-like. It will install the latest package from testing and its dependencies. Remove [testing] again and you can go on using your non-testing system. I don't know if it is fail-proof but it worked for me with xorg-server (to 1.8). When I'm doing a pacman -Syu it just says that the packages installed are newer and therefore doesn't update these certain packages.
This will only work if the package uses versioned depends, which is not always the case.
On Thu, 2010-05-20 at 18:04 -0400, Daenyth Blank wrote:
On Thu, May 20, 2010 at 18:05, Jeroen Op 't Eynde <jeroen@xprsyrslf.be> wrote:
There is a number 3.
3. Add [testing] and do a pacman -Sy package-you-like. It will install the latest package from testing and its dependencies. Remove [testing] again and you can go on using your non-testing system. I don't know if it is fail-proof but it worked for me with xorg-server (to 1.8). When I'm doing a pacman -Syu it just says that the packages installed are newer and therefore doesn't update these certain packages.
This will only work if the package uses versioned depends, which is not always the case. AND its a recipe for eventual system breakage...
On Fri, 21 May 2010 00:21:12 +0200, Ng Oon-Ee <ngoonee@gmail.com> wrote:
On Thu, 2010-05-20 at 18:04 -0400, Daenyth Blank wrote:
There is a number 3.
3. Add [testing] and do a pacman -Sy package-you-like. It will install the latest package from testing and its dependencies. Remove [testing] again and you can go on using your non-testing system. I don't know if it is fail-proof but it worked for me with xorg-server (to 1.8). When I'm doing a pacman -Syu it just says that the packages installed are newer and
On Thu, May 20, 2010 at 18:05, Jeroen Op 't Eynde <jeroen@xprsyrslf.be> wrote: therefore
doesn't update these certain packages.
This will only work if the package uses versioned depends, which is not always the case. AND its a recipe for eventual system breakage...
Ok, that wasn't a very safe step I took. :D As I said it worked for me and I got luck. The PKGBUILD has indeed versioned depends (most of them). -- Jeroen Op 't Eynde - jeroen@xprsyrslf.be - http://xprsyrslf.be To read: http://en.wikipedia.org/wiki/Posting_style#Bottom-posting Steun Jeugdhuis de PUT via Donamail: http://www.donamail.be/default.asp?btnID=iYOviYvW
On Thu, May 20, 2010 at 06:04:42PM -0400, Daenyth Blank wrote:
On Thu, May 20, 2010 at 18:05, Jeroen Op 't Eynde <jeroen@xprsyrslf.be> wrote:
There is a number 3.
3. Add [testing] and do a pacman -Sy package-you-like. It will install the latest package from testing and its dependencies. Remove [testing] again and you can go on using your non-testing system. I don't know if it is fail-proof but it worked for me with xorg-server (to 1.8). When I'm doing a pacman -Syu it just says that the packages installed are newer and therefore doesn't update these certain packages.
This will only work if the package uses versioned depends, which is not always the case.
Also, suppose you want package Z from testing, which depends on libfoo also in testing. And suppose that the libfoo update also mandated rebuilding package W, which depends on libfoo and is also in testing. If you just do "pacman -Sy Z", even if you *are* lucky enough to pull in libfoo too (as you will if Z has a versioned depends on libfoo), you'll probably still miss the update to W. So when you try to run the *old* W still on your system, with the newer libfoo installed, boom. That's why I said that the only reliably safe choice for binary installs is to update everything in testing which is connected by any chain of depends/requires relations to Z. Of course, in many cases you'll get away with doing less. And if you know what's in testing and why, you'll be able to better predict when doing less will suffice. But I think the only reliably safe general recipes are the two I stated. -- Jim Pryor profjim@jimpryor.net
Am 20.05.2010 19:29, schrieb Caleb Cushing:
I'm trying to help with the testing of perl 5.12 but I'd rather not test every package out there. Is it possible to block certain packages from being updated from testing? or only allow certain ones? maybe with a regex? obviously I don't wish to ban them globally. if they make it into a non testing repo I'm fine with it.
If you are careful, you can simply test a single package from testing. However, it might be necessary to also grab dependencies ... so you need to know what you are doing, why the package is in testing, what it depends on and what depends on it. As far as I know, perl is "alone" in testing, so you should be in the clear.
On Thu, May 20, 2010 at 6:31 PM, Thomas Bächler <thomas@archlinux.org> wrote:
As far as I know, perl is "alone" in testing, so you should be in the clear.
well it doesn't depend on anything but there are new perl-* packages that need to depend on it. I just don't feel like updating my kernel or xorg to test perl. but from what people are saying the automation of grabbing any updates to a subset of the packages in those repos is not possible. -- Caleb Cushing http://xenoterracide.blogspot.com
Am 21.05.2010 15:18, schrieb Caleb Cushing:
On Thu, May 20, 2010 at 6:31 PM, Thomas Bächler <thomas@archlinux.org> wrote:
As far as I know, perl is "alone" in testing, so you should be in the clear.
well it doesn't depend on anything but there are new perl-* packages that need to depend on it. I just don't feel like updating my kernel or xorg to test perl. but from what people are saying the automation of grabbing any updates to a subset of the packages in those repos is not possible.
No, there is no way to automate this process. We would need to split testing into several topic-repositories to do that.
participants (6)
-
Caleb Cushing
-
Daenyth Blank
-
Jeroen Op 't Eynde
-
Jim Pryor
-
Ng Oon-Ee
-
Thomas Bächler