Not sure SO is the best place to ask this, but it is development related so maybe someone can help.
I've written an app (in python but that's not important) which parses a Yum repo database to collate RPM packages and their dependencies. The problem I have is that I am sucking in too many packages when a dependency is met by more than one.
Specific example: I am seeking the list of packages which meet dependencies for Java-1.8.0 and getting a dependency of libjli.so()(64bit). libjli.so()(64bit) My code correctly works out that this is provided by multiple -devel packages from the Java 1.8, 1.7 and 1.6 streams. Unfortunately all three versions (and their dependencies) then get included in my list.
I guess my question is, given a list of packages meeting a requirement, what is the best way to identify the most appropriate package to include? i.e. when resolving the dependencies for Java-1.8.0, only include the -devel package for 1.8.0 and not suck in the -devel packages for 1.6 and 1.7 as well.
I know this is a problem with my code, I'm just not sure what facilities are provided by the yum ecosystem to help me identify which package would be best to include from the list of multiple.
It is hard to tell without seeing your code.
Yum is dead. If you are developing something new, you should develop on top of DNF. DNF use satsolver algorithm (https://doc.opensuse.org/projects/satsolver/11.4/index.html) and you can use libdnf https://github.com/rpm-software-management/libdnf (formerly known as libhif, formerly known as libhawkey).
Related
Many Cygwin's packages have no maintainer, is it still revelant to use Cygwin ?
I would like to update ruby or ansible package to the last version, how can I do that ?
Thanks
Package maintainers are volunteers.
Anyone can offer him/herself for the job.
Documentation
https://cygwin.com/packaging-contributors-guide.html
Mailing list for discussion about Maintainers
https://cygwin.com/mailman/listinfo/cygwin-apps
If you want to be a maintainer you must subscribe to the Cygwin mailing lists. All discussions about maintaining packages are there, and you will be required to post your credentials (i.e. public key) there in order to upload updated packages. Note that some orphan packages became so because the previous maintainer needed to reduce their workload.
Once you are subscribed, just ask to take over an orphaned package, upload your credentials, install the source package, make necessary changes, and upload the new package. It sounds easy, but you might want to build the package and make sure it runs all tests before asking to be the new maintainer.
Note that there may be others who have tried to update a package, and encountered blocking problems. Those will be discussed in the mailing lists, which you can search.
Although I am relatively new to using Linux, I would like to know more on how deploying packages works. I have tried searching for this but have had no luck. I have seen countless packages and install scripts that use the same looking 'graphical' command line install for the user to select options for the package. Take the Debian net install for example. [1]
As I have a lot to learn, I would only like a summary of how this is possible, and any resources that anyone has on how developers do this.
Thanks in advance.
[1] http://doudoulinux.org/blog/public/screenshots/install/install-selected-tasks.png
OK, now, i believe, i understand what you're after. I'll still insist that interactive configuration of packages is distro specific and shall not be the main form of package configuration.
It is preferred to ship in a default working configuration and then document how the user can change configuration files (normally in /etc) to reconfigure the package. It is often useful to ship several default configurations (example package: wpa_supplicant which ships with several examples of network configuration, all disabled by default) and allow the user to choose by uncommenting lines.
Debian
The debian specific way to get packages configured is debconf, its configuration is a simple shell script (or a perl script, or whatever else that can talk over STDIN/STDOUT) and a template file. The template file is what will provide options in the aptitude/apt-get interface as in the screenshot in your question.
It is worth reading the debian guidelines on package configuration to have an idea of which kind of configuration is too much.
And they also have a thorough tutorial. Since you said you do not have experience packaging i also recommend reading the introduction to packaging, which will tell you where the files shall be placed. Also, dbhelper is a great tool to place files in the correct place in the package directory.
On other distros
Each distro has its own way of adding configuration to packages. Debian is notable for its debconf as it is one of the most feature rich tools for configuring packages (together with dpkg-reconfigure).
Developers of the software that is sipped in a distro package are often different people from the ones that do the packaging. Configuration options left by developers are often much more thorough than in the package (e.g. inclusion or exclusion of certain libraries).
The fact that you're most familiar with the debian distro (that is an assumption based on your question tags), might give you a misleading idea of package configuration. Only debian based distros have so many configurable packages, other distros often use package dependencies to install differently configured packages. For example:
RedHat based distros (.rpm packages) have no tool such as debconf (as far as i am aware), they use distinct (conflicting) package names to install differently configured packages.
Arch Linux based distros enforce the user configuration. In essence, arch forces the user to configure their packages by going into their configuration files and changing the configuration (that is a very good thing if you want to learn).
Funny enough, both RPM and Arch based distros often ship po-debconf, an adapted debconf for that distro. Yet, i cannot tell much about it since i never tried it.
Coming from Ruby where I can have as many versions of every gem as I want, it's confusing to me why there is the restriction of Cabal being able to only have one version installed at the same time?
I've tried searching for an answer, but couldn't find anything explaining the reasoning behind this. And another good question would be if is there a workaround to this other than using sandboxes, which require me to recompile everything for every project (or share the sandbox, which doesn't always work).
edit: To clarify this question, what I don't understand is how cabal gets to the point where it says that installing a package would break another package. What is the cause of this issue?
I know it can be fixed by using a sandbox, but that's not an answer to the cause of this problem.
Your assumption is incorrect: cabal does allow installation of multiple versions of the same package. Packages are distinguished by version number.
Practically speaking, are these essentially synonymous? Or is there something I'm missing? I've use Composer (PHP), CocoaPods (Objective-C), and Bundler (Rails). I believe they describe themselves as dependency managers but can they also be consider as package mangers?
I'd say yes. Given that the javascript community calls their version of those tools (NPM and bower) "package managers", I think that the development community has essentially synonymized those terms.
EDIT I'm going to backtrack a bit. In general, I think the term package manager has to do with the delivery and installation of third party code. That said, npm is correctly named the node package manager. As I see it, a dependency manager is a different thing. It's an runtime orchestration tool. For example, there are dependency managers that simply run in the browser to load asset files in the proper order (think requireJS, browserify, cartero, etc... - or think a Dependency Injection container in say Symfony2 or Laravel) but you wouldn't call those package managers. A package manager would be something like Debian's dpkg or the node community's bower, which actually downloads third party libraries for you (that aren't currently in your software suite). Now, I think the burred lines come in when package managers decided to be smart enough to resolve version numbers for us. Because tools like npm make sure that each piece of software we declare has all of the proper versions of it's dependencies (by downloading a chain of dependencies for us), we want to call it a dependency manager. But I think it's more proper to say that it's a package manager that happens to do version resolution. It's really more of a delivery mechanism than a runtime tool, though.
All that to say, I'd like to hear what others have to say about this.
No, they are not synonyms. Look At that answer for their difference
https://stackoverflow.com/a/27290095/4016254
I'm developing an application using Python 3. What is the best practice to use third party libraries for development process and end-user distribution? Note that I'm working within these constraints:
Developers in the team should have the exact same version of the libraries.
An ideal solution would work on both Windows and Linux.
I would like to avoid making the user install software before using our own; that is, they shouldn't have to install product A and product B before using ours.
You could use setuptools to create egg files for your libraries, assuming they aren't available in egg form already. You could then bundle the eggs alongside your software, which would need to either install them, or ensure that they were on the import path.
This has some complexities, i.e. if your libraries have C-extensions, then your eggs become platform-specific, but in my experience this is the most widely-accepted means of 'bundling' stuff in Python.
I have to say that this remains one of Python's weaknesses, though; the third-party ecosystem is certainly aimed at developers rather than end-users.
There are no best practices, but there are a few different tracks people follow. With regard to commercial product distribution there are the following:
Manage Your Own Package Server
With regard to your development process, it is typical to either have your dev boxes update from a local package server. That allows you to "freeze" the dependency list (i.e. just stop getting upstream updates) so that everyone is on the same version. You can update at particular times and have the developers update as well, keeping everyone in lockstep.
For customer installs you usually write an install script. You can collect all the packages and install your libs, as well as the other at the same time. There can be issues with trying to install a new Python, or even any standard library because the customer may already depend on a different version. Usually you can install in a sandbox to separate your packages from the systems packages. This is more of a problem on Linux than Windows.
Toolchain
The other option is to create a toolchain for each supported OS. A toolchain is all the dependencies (up to, but not including base OS libs like glibc). This toolchain gets packaged up and distributed for both developers AND customers. Best practice for a toolchain is:
change the executable to prevent confusion. (ie. python -> pkg_python)
don't install in .../bin directories to prevent accidental usage. (ie. on Linux you can install under .../libexec. /opt is also used although personally I detest it.)
install your libs in the correct location under lib/python/site-packages so you don't have to use PYTHONPATH.
Distribute the source .py files for the executables so the install script can relocate them appropriately.
The package format should be an OS native package (RedHat -> RPM, Debian -> DEB, Win -> MSI)
For developers use PIP with requirements file.
For end users, specify requirements in setup.py.