I have a set of yum repositories. I have a large collection of rpms from http://pkgs.repoforge.org/. I don't want to import some of those rpms due to conflicts that they would cause. I'd like to figure out which of the remaining rpms I can import and also satisfy dependencies.
I can figure out what each rpm provides. I know that I can do a yum provides foo to figure out where to get foo from. So I can figure out the dependencies. However yum is slow to startup. I really don't want to spend a day or so calling it over and over again while I am figuring out my dependency graph.
Is there any way to convince yum to give me a bulk dump of what is available in one call? Kind of like yum list all but instead of listing packages, list everything that is provided by any package that yum knows about?
You can use:
yum provides '*'
and you get list all files from each repository.
There's also:
repoquery --tree-provides
repoquery --tree-requires
repoquery --tree-whatrequires
...depending on what you want. The latest upstream allows you to output in DOT format too.
Related
I have a Python library (https://github.com/jcrozum/PyStableMotifs) that I want to publish on PyPI. It depends on another library (https://github.com/hklarner/PyBoolNet) that I do not control and that is only available on GitHub, and in particular, it is not available on PyPI. My setup.py looks like this:
from setuptools import
setup(
... <other metadata> ...,
install_requires=[
'PyBoolNet # git+https://github.com/hklarner/PyBoolNet#2.3.0',
... <other packages> ...
]
)
Running pip install git+https://github.com/jcrozum/PyStableMotifs works perfectly, but I can't upload this to PyPI because of the following error from twine:
Invalid value for requires_dist. Error: Can't have direct dependency: 'PyBoolNet # git+https://github.com/hklarner/PyBoolNet#2.3.0'
My understanding is that direct links are forbidden by PyPI for security reasons. Nonetheless, PyBoolNet is a hard requirement for PyStableMotifs. What do I do? Give up on PyPI?
I just want pip install PyStableMotifs to work for my users. Ideally, this command should install the dependencies and I should not have to maintain two versions of setup.py.
Failing that, I have considered creating a "dummy" package on PyPI directing users to install using the command pip install git+https://github.com/jcrozum/PyStableMotifs. Is this a bad idea (or even possible)?
Are there already established best practices for this situation or other common workarounds?
EDIT:
For now, I have a clunky and totally unsatisfying workaround. I'm keeping two versions; a GitHub version that works perfectly, and a PyPI version that has the PyBoolNet requirement removed. If the user tries to import PyStableMotifs without PyBoolNet installed, an error message is shown that has install instructions for PyBoolNet. This is far from ideal in my mind, but it will have to do until I can find a better solution or until PyPI fixes this bug (or removes this feature, depending on who you ask).
My recommendation would be to get rid of the direct URL in install_requires, and tell your users where they can find that dependency PyBoolNet since it is not on PyPI. Don't force them on a specific installation method, but show them an example.
Maybe simply tell your users something like:
This project depends on PyBoolNet, which is not available on PyPI. One place where you can find it is at: https://github.com/hklarner/PyBoolNet.
One way to install PyStableMotifs as well as its dependency PyBoolNet is to run the following command:
python -m pip install 'git+https://github.com/hklarner/PyBoolNet#2.3.0#egg=PyBoolNet' PyStableMotifs
You could additionnally prepare a requirements.txt file and tell your users:
Install with the following command:
python -m pip install --requirement https://raw.githubusercontent.com/jcrozum/PyStableMotifs/master/requirements.txt
The content of requirements.txt could be something like:
git+https://github.com/hklarner/PyBoolNet#2.3.0#egg=PyBoolNet
PyStableMotifs
But in the end, you should really let your users choose how to install that dependency. Your project only need to declare that it depends on that library but not how to install it.
It is common practice to customize a Yocto made package with an Bit Bake append file _%.bbappend. The problem I am having is even though the package contents have been modified due to the append file, the package keeps the same version number. This is troublesome because dnf install will not install the RPM because it does not think it is an upgrade and a dnf remove before would trigger dependent packages to also be removed. There are ways around this modifying DNF configs, but I get nervous automating those changes in utilities due to the chance of really nasty error states.
Assuming the original package is installed, is there any way to modify the Bit Bake append file so that dnf will install the result like an updated package?
The solution to this is to use the PR service:
https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#working-with-a-pr-service
I believe you want to set (and increment as you update) the PR variable as follows:
PR = "r1"
See: https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#var-PR
I can't seem to find anything useful in the man pages etc for this, but it seems like it should be straightforward..?
Our servers are running CentOS 6.8 but also have the Atomic repository for some package versions. The most recent version of one of the packages that Atomic provides seems to be broken, so we've had to do a yum downgrade of that package.
Problem now is that we're running Plesk, which performs automatic Yum updates on a schedule, and the next time this happens, the broken package will just drag back in again!
All I want to do is tell Yum to ignore this specific package version so that it updates the next time there's a newer version, but skips the current.
I found that I can add exclude= lines to yum.conf but I can't seem to find how to define a specific version number in this exclude. It looks like I can only exclude entire package names?
I'm more familiar with Gentoo where we can tell Portage to mask specific versions when problems like this occur. Is this not an option in CentOS?
Much appreciated.
I was wondering whether there are version capabilities with yum groups, correlating group versions with RPM versions.
To give a more concrete example what I would finally like to accomplish for my custom repo is something like this concept:
Let's say we have a grouping (only conceptual at this point) of RPMs (e.g A.rpm, B.RPM) that together constitute a e.g Platform. These rpm have versions so we have A-0.1.rpm, A-0.2.rpm, B-0.1.rpm, B-0.2.rpm etc.
My question is, if it is somehow possible to group the different versions of the individual RPMs in a versioned group. I have done some research on yum groups but it seems that it can't handle versions. Ideally I would like to have something like yum groupinstall "MyPlastform-0.1" that installs A-0.1.rpm and B-0.1.rpm and yum groupinstall "MyPlastform-0.2" that installs A-0.2.rpm and B-0.2.rpm, or something similar.
Please note that RPMs A and B should not have dependencies with each other.
Can this be accomplished?
I'm just shooting blindly here but why don't you use a "virtual package" that essentially depends on other packages with specific versions. you can version this package as well.
Hence,
MyPlatform-v1.0 is a package that depends on A-0.1 and B0.1
MyPlatform-v1.1 is a package that depends on A-0.2 and B0.1
It's similar to what apt did with the "build-essentials".
I have created a relocatable RPM using the instructions in this website:
http://www.cyberciti.biz/faq/rpm-relocatable-packages/
This means that I can install the package into its default location, /opt/app, using
rpm -ivh mypackage.rpm
However, if I decide that I weant the package to be installed into /usr/local/bin instead, I can install it using:
rpm -ivh --prefix=/usr/local/bin mypackage.rpm
All of this works perfectly. However, I need to install the package via Yum. How do I pass the --prefix argument to Yum?
I don't believe this is possible and a quick online search seems to concur. Including this mailing list thread from 2007. The point that Seth Vidal makes in his reply is, I think, the main one. Relocations cause problems for file-based dependency tracking which, at least at the time, nothing bothered to handle.
That being said I think the utility of relocatable RPMs is likely not very high as building one that functions correctly is difficult as not being able to depend on file locations makes many (normally trivial) programmatic operations quite difficult.