Is it possible for single rpm package to belong to several groups?
In spec file you can set package group:
Group: System Environment/Base
What I need is to be able to set several groups for this package (like System|Util|MyCompanyName) - they would be like tags assigned to the package.
When the package is installed I want to query it like
rpm -q --group System
or
rpm -q --group MyCompanyName
and in both cases I should see my package (and others belonging to this group)
Edit:
Many packages may belong to MyCompanyName group, but only few may be installed. I need a way to differentiate our packages from linux system packages - I was planning to do it using the group name
I tried putting several Group: lines, but it only uses the last one. Everything after Group: seems to be taken as one string and I couldn't find a way to split them.
Another solution that I could think of is putting this stuff as PROVIDES and then to query
rpm -q --whatprovides System
but I don't like it this way.
Is there other way to accomplish the requested functionality?
The correct way to specify your company name is via the Vendor tag like this:
Vendor: Yoyodyne, Inc.
To get a list of packages by vendor you can run this command:
rpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -v Yoyodyne
An RPM can only belong to one group. Furthermore, the allowable groups is defined by the distribution.
To find the valid groups for a particular distribution you must often run the package manager for that distro and look at the list.
RPM is not nearly as well defined as the Debian package format is. There seems to be no official or thorough documentation.
http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
AFAIU, RPMs should belong to a single Group in RPM's GROUPS file or have Group unspecified. Cannot have more than one.
You might be able to define the groups at the repo-level instead of the package level using yum groups. Once you have your groups defined, you should be able yo use the 'yum groupinfo' command to see the packages in each group.
This is an old post but since it still shows up on Google;
Nowadays at least OpenSUSE uses the Group: field as a space-separated tags field instead of an hierarchial tree, so for SUSE packages you can simply space separate the tags you'd like your package to belong to.
See: https://en.opensuse.org/openSUSE:Package_group_guidelines for details.
Related
Is it possible to set up a custom section in the pipfile?
By default I see only [packages] and [dev-packages], but I have extra dependencies for some environment. So I want to install packages and for example [tests] but not [dev-packages].
E.G.:
pipenv install --tests
# or
pipenv install --my-custom-section
Before that I used requirements.txt, requirements-dev.txt, requirements-integration.txt. Is there any good way to implement it with pipenv?
Let's look into documentation
If we look in Pipfile. The Concept:
Pipfile will be superior to requirements.txt file in a number of ways:
...
Existing requirements files tend to proliferate into multiple files - e.g. dev-requirements.txt, test-requirements.txt, etc. - but a Pipfile will allow seamlessly specifying groups of dependencies in one place. * This will be surfaced as only two built-in groups (default & development). (see note below)
Note
Custom groups may be added in the future. Remember, it is easier to add features in the future than it is to remove them. The Composer community has been successful with only default and development as group options for many years. This model is being followed.
Answer
It's not possible now although it was designed with idea of such possibility.
Maybe it will be possible in future.
I work with the Yocto Project quite a bit and a common challenge is determining why (or from what recipe) a file has been included on the rootfs. This is something that can hopefully be derived from the build system's environment, log & meta data. Ideally, a set of commands would allow linking a file back to a source (ie. recipe).
My usual strategy is to perform searches on the meta data (e.g. grep -R filename ../layers/*) and searches on the internet of said filenames to find clues of possible responsible recipes. However, this is not always very effective. In many cases, filenames are not explicitly stated within a recipe. Additionally, there are many cases where a filename is provided by multiple recipes which leads to additional work to find which recipe ultimately supplied it. There are of course many other clues available to find the answer. Regardless, this investigation is often quite laborious when it seems the build system should have enough information to make resolving the answer simple.
This is exact use case for oe-pkgdata-util script and its subcommand find-path. That script is part of openembedded-core.
See this example (executed in OE build environment, i.e. bitbake works):
tom#pc:~/oe/build> oe-pkgdata-util find-path /lib/ld-2.24.so
glibc: /lib/ld-2.24.so
You can clearly see that this library belongs to glibc recipe.
oe-pkgdata-util has more useful subcommands to see information about packages and recipes, it worth to check the --help.
If you prefer a graphical presentation, the Toaster web UI will also show you this, plus dependency information.
The candidate files deployed for each recipe are placed in each $WORKDIR/image
So you can cd to
$ cd ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}
and perform a
$ find . -path '*/image/*/fileYouAreLookingFor'
from the result you should be able to infer the ${PN} of the recipe which deploys such file.
For example:
$ find . -path '*/image/*/mc'
./bash-completion/2.4-r0/image/usr/share/bash-completion/completions/mc
./mc/4.8.18-r0/image/usr/share/mc
./mc/4.8.18-r0/image/usr/bin/mc
./mc/4.8.18-r0/image/usr/libexec/mc
./mc/4.8.18-r0/image/etc/mc
I maintain a commercial, binary package for debian, ubuntu, & etc. and have gotten complaints about "bad package quality" from the Ubuntu installer. The root cause of this appears to be that the package installs files in the /opt and /etc/opt directories which apparently throws lintian into a hissy fit. As I understand the purpose of these directories, they are meant to serve the needs of "Add-on" applications although I have yet to see any definition of what "add-on" is supposed to mean. I have attempted to create a lintian override file for my package in the /usr/share/lintian/overrides directory and, when I do so, I get the following report from Lintian:
N: Some overrides were ignored, since the tags were marked "non-overridable".
N: The following tags were "non-overridable" and had at least one override
N: - dir-or-file-in-opt
Is there any way around this apparent obstinacy?
If you're using debhelper to build your package, lintian overrides for the binary packages should go in the debian folder with the filename [package].lintian-overrides. This ensures the overrides make it into the proper directory on package installation. (For source packages, overrides go in the file debian/source/lintian-overrides.)
That said, short of not putting your files in /opt, I'm not sure there's a way to completely get rid of the dir-or-file-in-opt lintian complaint. Though, I'm not sure it's necessary since, to my knowledge, the ubuntu/aptdaemon lintian profile (which disables the dir-or-file-in-opt tag) is used in most of the situations in which lintian would be run automatically during/before package installation. That's probably not quite the answer you were hoping for, but I hope it's helpful nonetheless!
Sources:
Debian New Maintainers' Guide, section 5.14
Lintian User's Manual, section 2.4
Cendio ThinLinc bug #5232
I am dealing with making some packages of some projects.
Assume I have a config file like that in my project.
name=foo
mail=foo#foo.com
After installation user edits config file with his/her information.
name=user
mail=user#somedomain.com
When a update comes, for the purpose of not ruin the users config file, I do not replace conf file with new ones as all packages should do.
There is no problem up to this point.
What if I add a new parameter to my config file? For example,
name=foo
mail=foo#foo.com
age=23
If I replace config file with new one, user will lost its settings. If I don't, my new parameter could not be used. I wonder what is the general procedures for this conditions? My question is valid no matter what package types it is (i.e. rpm, deb or tbz).
#William Pursell: Just because you don't see the problem, that does not mean that there isn't a problem.
This definitively is a problem and it has plagued me since I maintain deb packages. For example: many configuration files contain commented configuration items and other comments that the package user is supposed to read and understand before applying his configuration changes. If, in the normal course of software development, there are new configuration items, new default values, or different semantics to existing ones, the comments have to be adapted. This is the package maintainer's job. But at the same time, the package must not mess with the configuration changes already applied by the user.
When I do this in Debian/Ubuntu, the package user is confronted with this intimidating question:
Configuration file `/etc/...'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** ... (Y/I/N/O/D/Z) [default=N] ?
for every single file. That is, for some package upgrades, the user has to type yes/no/maybe :-) many times, every time. Fact is that the package user usually does not know what this is all about. She has to dig into the files, diff versions, and do some guessing in order to figure out a reasonable answer. An answer, by the way, that the package maintainer could have made already, if the packaging system would allow it.
I recognize that there may not exist a general solution to this problem. But I'd love to hear how other package maintainers cope with the situation.
I'm not sure I see the problem. As long as the software can handle the absence of the field in the config file (ie, use a reasonable default), then there is no difference in the two scenarios you describe. If you software cannot handle the absence of the field, I would argue that is a bug.
In this instance I'm using c with autoconf, but the question applies elsewhere.
I have a glade xml file that is needed at runtime, and I have to tell the application where it is. I'm using autoconf to define a variable in my code that points to the "specified prefix directory"/app-name/glade. But that only begins to work once the application is installed. What if I want to run the program before that point? Is there a standard way to determine what paths should be checked for application data?
Thanks
Thanks for the responses. To clarify, I don't need to know where the app data is installed (eg by searching in /usr,usr/local,etc etc), the configure script does that. The problem was more determining whether the app has been installed yet. I guess I'll just check in install location first, and if not then in "./src/foo.glade".
I dont think there's any standard way on how to locate such data.
I'd personally do it in a way that i'd have a list of paths and i'd locate if i can find the file from anyone of those and the list should containt the DATADIR+APPNAME defined from autoconf and CURRENTDIRECTORY+POSSIBLE_PREFIX where prefix might be some folder from your build root.
But in any case, dont forget to use those defines from autoconf for your data files, those make your software easier to package (like deb/rpm)
There is no prescription how this should be done in general, but Debian packagers usually installs the application data somewhere in /usr/share, /usr/lib, et cetera. They may also patch the software to make it read from appropriate locations. You can see the Debian policy for more information.
I can however say a few words how I do it. First, I don't expect to find the file in a single directory; I first create a list of directories that I iterate through in my wrapper around fopen(). This is the order in which I believe the file reading should be done:
current directory (obviously)
~/.program-name
$(datadir)/program-name
$(datadir) is a variable you can use in Makefile.am. Example:
AM_CPPFLAGS = $(ASSERT_FLAGS) $(DEBUG_FLAGS) $(SDLGFX_FLAGS) $(OPENGL_FLAGS) -DDESTDIRS=\"$(prefix):$(datadir)/:$(datadir)/program-name/\"
This of course depends on your output from configure and how your configure.ac looks like.
So, just make a wrapper that will iterate through the locations and get the data from those dirs. Something like a PATH variable, except you implement the iteration.
After writing this post, I noticed I need to clean up our implementation in this project, but it can serve as a nice start. Take a look at our Makefile.am for using $(datadir) and our util.cpp and util.h for a simple wrapper (yatc_fopen()). We also have yatc_find_file() in case some third-party library is doing the fopen()ing, such as SDL_image or libxml2.
If the program is installed globally:
/usr/share/app-name/glade.xml
If you want the program to work without being installed (i.e. just extract a tarball), put it in the program's directory.
I don't think there is a standard way of placing files. I build it into the program, and I don't limit it to one location.
It depends on how much customising of the config file is going to be required.
I start by constructing a list of default directories and work through them until I find an instance of glade.xml and stop looking, or not find it and exit with an error. Good candidates for the default list are /etc, /usr/share/app-name, /usr/local/etc.
If the file is designed to be customizable, before I look through the default directories, I have a list of user files and paths and work through them. If it doesn't find one of the user versions, then I look in the list of default directories. Good candidates for the user config files are ~/.glade.xml or ~/.app-name/glade.xml or ~/.app-name/.glade.xml.