Hot answers tagged package-management
Based on the output, you're mixing i686 and i386 packages together. You need to take care that you have the appropriate archiecture (i386, i686, x86_64, etc.) for your system's hardware and the other packages you have installed. So in your case yum is correctly complaining that you don't have the i386 versions of the dependencies installed already. Error: ...
In Linux Mint 17 Qiana, Synaptic "officially" lacks the upgrade feature. This is for sake of stability - users are supposed to use mintupdate for already-installed packages. Synaptic can still be used to install additional, new packages.
The closest to BSD ports is Gentoo Linux's Portage: http://wiki.gentoo.org/wiki/Portage P.S. I have positive experience with building Debian/Ubuntu packages from source, but that's not your main question, so I'm not going to get into details.
The separated repository is two fold: To keep all security related upgrades easily identifiable, since they come from a different domain and with different suite. To expedite all the security related upgrades and provide an unique mirror to assure maximum availability in the shortest time, since mirrors sync with Debian's on regular basis which defeats the ...
I would suggest not doing this. It's generally easier to build binaries for the different distros within that distro's package building process. On CentOS, that would be making use of rpmbuild. Since you're dealing with VMs it would be much more trivial to setup a CentOS 7 VM + build tools and then do the package construction there. Observations from a ...
To answer the question more directly. Yes downgrading can cause screwey problems with other software. And what you downgrade may not fit with dependencys that are not downgraded. Which is part of why its not supported. While I find downgrading necessary at times it can be problematic....
An alternative answer, addressing your concern from a different angle, is to build your packages with testing on a more powerful machine. Then when needed copy the closure to the remote host. This works well if you are on the same architecture and the software in question is not tightly coupled to any hardware which is different on the two machines. Read ...
I see you trying to use disableTest found in haskell-package.nix to remove testing from the lens packages. I would have to do some testing to tell you exactly why it is not meeting your needs. I have disabled testing in general overriding the cabal package in config.nix to cabalNoTest. This overrides the cabal package used by the rest of the haskell ...
For my situation, I found the solution to be distcc, which eyoung100 suggested in the comments.
You might want to look at Sabayon Linux, a child of Gentoo. It uses pre-compiled packages, a.k.a binaries stored in repos, that are remote. What actually happens is that maintainers configure the package using predetermined USE Flags, and then compile the package with portage. Then using the Sabayon Binary Package Manager, Entropy, the maintainers upload ...
On NetBSD, you usually upgrade pkgsrc to the latest version (which is nothing more than tar -xvzf pkgsrc-version.tar.gz) and updates the installed software individually. More information on the NetBSD/pkgsrc website: http://wiki.netbsd.org/pkgsrc/how_to_use_pkgsrc/#index1h2 http://wiki.netbsd.org/pkgsrc/how_to_use_pkgsrc/#index7h1 Hope this helps!
I needed to get updates because I installed bash and didn't want to suffer from the Shellshock vulnerability, so I went with Holu's suggestion http://unix.stackexchange.com/a/103661/93476 and it got me patched up.
Only top voted, non community-wiki answers of a minimum length are eligible