[opensuse-packaging] How to force a forked package to stay?
Let's say I have a fork of one of the packages that comes with system core. That fork is targeted for very special target audience or special use-cases, so please no flaming on the topic of how wrong is it to do something like that... But, that fork consists of libs and devel packages, and every time update for this package comes in main repository - it gets replaced with updated non- forked version. Or someone installs lib from official version and devel from forked version, which is again wrong. What is the recommended way to force a pair of those packages to stay in the system? I can think of some ways to do it: * add custom provides to the spec file and make devel version require certain provider of lib. But that will only protect from installing incompatible versions of devel and lib packages, but not from installing both of them. * add synthetic package that will depend on first two, again by certain custom providers. This means that update will not be installed because other package has a dependency for that provider. But yast update will complain every time about that, and yes that does not sound very good. * bump a version to 99.%{version}, to make it the newest existing provider for both library and devel. But devel will have to require exactly the same version. So, for that use-case, should I use any of those workarounds, or there is better way of doing it? -- Regards, Stas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2014-12-17 18:57, Stanislav Baiduzhyi wrote:
Let's say I have a fork of one of the packages that comes with system core. But, that fork consists of libs and devel packages, and every time update for this package comes in main repository - it gets replaced with updated non- forked version. Or someone installs lib from official version and devel from forked version, which is again wrong.
What is the recommended way to force a pair of those packages to stay in the system?
I can think of some ways to do it:
* add custom provides to the spec file and make devel version require certain provider of lib.
This.
But that will only protect from installing incompatible versions of devel and lib packages, but not from installing both of them.
Both of what? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 17 December 2014 19:15:38 Jan Engelhardt wrote:
On Wednesday 2014-12-17 18:57, Stanislav Baiduzhyi wrote:
Let's say I have a fork of one of the packages that comes with system core. But, that fork consists of libs and devel packages, and every time update for this package comes in main repository - it gets replaced with updated non- forked version. Or someone installs lib from official version and devel from forked version, which is again wrong.
What is the recommended way to force a pair of those packages to stay in the system?
I can think of some ways to do it: * add custom provides to the spec file and make devel version require certain> provider of lib.
This.
But that will only protect from installing incompatible versions of devel and lib packages, but not from installing both of them.
Both of what?
Both library and devel package. I mean, if I will have forked lib and devel installed, and there is update for lib and devel in main repository, update will replace both of them. -- Regards, Stas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2014-12-17 23:01, Stanislav Baiduzhyi wrote:
But that will only protect from installing incompatible versions of devel and lib packages, but not from installing both of them.
[...]If I will have forked lib and devel installed, and there is update for lib and devel in main repository, update will replace both of them.
`zypper up` won't do such replacements that would incur a vendor switch. To “survive” past `zypper dup`, you can make a metapackage which is basically empty (you will need a dummy file in it), and otherwise has Require: lines, such as "mylib(myfeature)", the latter of which is what is to be added to your library subpackage. (Example of all this is jeng-user-packages in http://jftp.inai.de/openSUSE_13.2 for example.) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 17 Dec 2014 23:22:45 +0100 (CET) Jan Engelhardt <jengelh@inai.de> wrote:
On Wednesday 2014-12-17 23:01, Stanislav Baiduzhyi wrote:
But that will only protect from installing incompatible versions of devel and lib packages, but not from installing both of them.
[...]If I will have forked lib and devel installed, and there is update for lib and devel in main repository, update will replace both of them.
`zypper up` won't do such replacements that would incur a vendor switch.
Just give the special case repository a higher priority. that should help in the zypper dup case too. but it means all packages coming from this repository will be preferred.
To “survive” past `zypper dup`, you can make a metapackage which is basically empty (you will need a dummy file in it), and otherwise has Require: lines, such as "mylib(myfeature)", the latter of which is what is to be added to your library subpackage.
(Example of all this is jeng-user-packages in http://jftp.inai.de/openSUSE_13.2 for example.)
Soon you wont need meta packages anymore. zypper dup finally learned an useful mode with extra repositories. see: https://bugzilla.suse.com/show_bug.cgi?id=893807 Though one question remains, why is your change only useful for a special community and not the rest of openSUSE? what problem are you trying to solve? with kind regards darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2014-12-17 23:28, Marcus Rueckert wrote:
`zypper up` won't do such replacements that would incur a vendor switch.
Just give the special case repository a higher priority. that should help in the zypper dup case too. but it means all packages coming from this repository will be preferred.
Not desired (at least in my case).
To “survive” past `zypper dup`, you can make a metapackage which is basically empty (you will need a dummy file in it), and otherwise has Require: lines, such as "mylib(myfeature)", the latter of which is what is to be added to your library subpackage.
(Example of all this is jeng-user-packages in http://jftp.inai.de/openSUSE_13.2 for example.)
Soon you wont need meta packages anymore.
Well I still want them for easy initial installation of the package group. (Might convert it to a pattern.)
Though one question remains, why is your change only useful for a special community and not the rest of openSUSE? what problem are you trying to solve?
Like, color schemes for editors, shells, etc. Customization. Some maintainers may not be willing to maintain the extra efforts required in SUSE packages to facilitate pluggable schemes (i.e. at the rpm level) with some software. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2014-12-18 00:22:49 +0100, Jan Engelhardt wrote:
Like, color schemes for editors, shells, etc. Customization. Some maintainers may not be willing to maintain the extra efforts required in SUSE packages to facilitate pluggable schemes (i.e. at the rpm level) with some software.
Well as long it is just "build this extra stuff as plugin" it shouldnt be too much effort to build it as part of the distro. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2014-12-18 00:38, Marcus Rueckert wrote:
On 2014-12-18 00:22:49 +0100, Jan Engelhardt wrote:
Like, color schemes for editors, shells, etc. Customization. Some maintainers may not be willing to maintain the extra efforts required in SUSE packages to facilitate pluggable schemes (i.e. at the rpm level) with some software.
Well as long it is just "build this extra stuff as plugin" it shouldnt be too much effort to build it as part of the distro.
Well, consider for example "htop", which draws its utilization gauges using the "|" character, and the lousy patch I have changes that to use {something that resembles ACS_BLOCK aka U+2588} instead. That's not going to become a plugin or a pluggable RPM package in any way. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 17 December 2014 23:28:47 Marcus Rueckert wrote:
On Wed, 17 Dec 2014 23:22:45 +0100 (CET)
Jan Engelhardt <jengelh@inai.de> wrote:
On Wednesday 2014-12-17 23:01, Stanislav Baiduzhyi wrote:
But that will only protect from installing incompatible versions of devel and lib packages, but not from installing
both of them.
[...]If I will have forked lib and devel installed, and there is update for lib and devel in main repository, update will replace both of them.
`zypper up` won't do such replacements that would incur a vendor switch.
Just give the special case repository a higher priority. that should help in the zypper dup case too. but it means all packages coming from this repository will be preferred.
I would like to make it as dump as possible, to be able to resolve all that stuff on the simplest level possible, including plain rpm commands.
To “survive” past `zypper dup`, you can make a metapackage which is basically empty (you will need a dummy file in it), and otherwise has Require: lines, such as "mylib(myfeature)", the latter of which is what is to be added to your library subpackage.
(Example of all this is jeng-user-packages in http://jftp.inai.de/openSUSE_13.2 for example.)
Soon you wont need meta packages anymore. zypper dup finally learned an useful mode with extra repositories. see: https://bugzilla.suse.com/show_bug.cgi?id=893807
Though one question remains, why is your change only useful for a special community and not the rest of openSUSE? what problem are you trying to solve?
Case I was thinking about is a development/experimental build of older openjdk packages, with "slowdebug" and some additional linked libs. Target audience is basically me and maybe couple of other guys working on specific part of openjdk source code, and those packages are usually installed inside the VM. So it is absolutely incompatible with jpackage, probably any app linked against libjvm.so will crash, performance regression will be huge, and the package most probably will be just deleted at some later point. In other words, I am as the author of package will not use it seriously myself, and would strongly recommend everyone avoid those packages by all possible means. But for this case I want to be sure that my horrible build is the only java provider installed in the system, and that newer releases will replace it even if someone will just run "rpm -Uhv *.rpm". Which excludes zypper config, and forces me to rely on dirty cheats and hacks, like version prefix or additional dependent package. -- Regards, Stas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Stanislav Baiduzhyi <baiduzhyi.devel@gmail.com> writes:
* add synthetic package that will depend on first two, again by certain custom providers. This means that update will not be installed because other package has a dependency for that provider. But yast update will complain every time about that, and yes that does not sound very good.
Does it help to add a conflict? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Andreas Schwab -
Jan Engelhardt -
Marcus Rueckert -
Stanislav Baiduzhyi