Hi,
I have a package (kubernetes) which I would like to decompose into 2 subpackages A and B. Problem is A and B share some files and directories so installing both of them on the same machine results in file conflicts. Solution is to create the third package C, which provides all those conflicting/shared files and directories (documentation, one configuration file, etc.). So A and B both Requires C. So now both A and B can be installed on the same machine (together with C).
My question is how should I name subpackage C? Should it be named common or shared or base or "this files and directories are shared together package". Is there a convention on naming a subpackage with these common or shared files and directories?
E.g.
glibc-common provides configuration file, binaries, locales emacs-common provides binaries, service file, documents, charsets, images, ... gnuplot-common provides binaries, docs, PostScript files, one man page, one info page, ...
Is there a minimum requirement what should a common package provide or is it just arbitrary?
Subpackage C provides one directory, one configuration file and 4 docs.
Thanks for any answer.
Kind Regards Jan
On 04/28/2015 03:15 PM, Jan Chaloupka wrote:
Hi,
I have a package (kubernetes) which I would like to decompose into 2 subpackages A and B. Problem is A and B share some files and directories so installing both of them on the same machine results in file conflicts.
Another way of avoiding this problem is to make sure these files are 100% identical. This includes modification time, user, permissions and of course content.
But as you are using the same files from the identical build I kinda wonder where such differences could come from...
Florian
On 04/28/2015 03:40 PM, Florian Festi wrote:
On 04/28/2015 03:15 PM, Jan Chaloupka wrote:
Hi,
I have a package (kubernetes) which I would like to decompose into 2 subpackages A and B. Problem is A and B share some files and directories so installing both of them on the same machine results in file conflicts.
Another way of avoiding this problem is to make sure these files are 100% identical. This includes modification time, user, permissions and of course content.
At a time of installation of both packages this holds.
But as you are using the same files from the identical build I kinda wonder where such differences could come from...
The only problem are this directory and configuration file: /etc/kubernetes /etc/kubernetes/config
which are supposed to be the same. However who can make sure, given A is installed, that someone does not change content of config and then installs B.
I updated packages A and B the way both now own /etc/kubernetes/config. Then installed package A, modified config file. rpm -V reported config file is changed. However after installing package B there was no conflict, installation was succesful. Which brings me to a point, if the config file is %config(noreplace) and it is edited (content, modification time or checksum changed), is update without conflicts? In general if I have a configuration file (with %config(noreplace)) which was modified and a set of packages all of them owning the configuration file, will there be any conflict of any of the packages gets updated or installed? So far on my use case on Fedora update is possible.
Looking into [1] which talks about %config(noreplace), there is no such information.
[1] http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html
Florian
On 04/28/2015 03:40 PM, Florian Festi wrote:
On 04/28/2015 03:15 PM, Jan Chaloupka wrote:
Hi,
I have a package (kubernetes) which I would like to decompose into 2 subpackages A and B. Problem is A and B share some files and directories so installing both of them on the same machine results in file conflicts.
Another way of avoiding this problem is to make sure these files are 100% identical. This includes modification time, user, permissions and of course content.
This is not correct.
Time stamps should not matter. If these matter now, something has regressed in rpm etc. (We've discussed this many times with Panu). Contents matter, these need to be 100% identical.
Ralf
On Tue, 2015-04-28 at 15:15 +0200, Jan Chaloupka wrote:
Is there a minimum requirement what should a common package provide or is it just arbitrary?
There's no real requirement. Personally 'common' is the name I'd most likely expect, with one proviso; I kinda expect a package named 'common' to be basically useless on its own, and exist *solely* for this purpose (to provide resources shared between two other packages). If the shared package contains enough stuff to actually be useful in some way on its own, I'd probably expect it to have another name, like 'core'.
On 05/01/2015 01:20 AM, Adam Williamson wrote:
On Tue, 2015-04-28 at 15:15 +0200, Jan Chaloupka wrote:
Is there a minimum requirement what should a common package provide or is it just arbitrary?
There's no real requirement. Personally 'common' is the name I'd most likely expect, with one proviso; I kinda expect a package named 'common' to be basically useless on its own, and exist *solely* for this purpose (to provide resources shared between two other packages). If the shared package contains enough stuff to actually be useful in some way on its own, I'd probably expect it to have another name, like 'core'.
Adam, thanks for sharing. I like this idea.