[opensuse-factory] Establishing policy on packages owning files at /etc/alternatives/*
Hi everyone! Problem: Currently the files at /etc/alternatives/* are a mix of files owned by some packages, and not owned by any package: vcuadradojuan@viccuad ~$ rpm -qf /etc/alternatives/* file /etc/alternatives/alternate-install-present is not owned by any package python-boto-2.38.0-5.2.noarch gawk-4.1.3-4.5.x86_64 gawk-4.1.3-4.5.x86_64 python-boto-2.38.0-5.2.noarch python-boto-2.38.0-5.2.noarch python-boto-2.38.0-5.2.noarch file /etc/alternatives/coverage is not owned by any package python-boto-2.38.0-5.2.noarch file /etc/alternatives/ctags is not owned by any package file /etc/alternatives/ctags.1 is not owned by any package python-boto-2.38.0-5.2.noarch ... If you see upstream usage for update-alternatives (Debian), all those files in /etc/alternatives/* are not owned by any package: vic@clotho ~$ dpkg -S /etc/alternatives/* dpkg-query: no path found matching pattern /etc/alternatives/aclocal dpkg-query: no path found matching pattern /etc/alternatives/aclocal.1.gz dpkg-query: no path found matching pattern /etc/alternatives/animate dpkg-query: no path found matching pattern /etc/alternatives/animate.1.gz dpkg-query: no path found matching pattern /etc/alternatives/appletviewer dpkg-query: no path found matching pattern /etc/alternatives/appletviewer.1.gz dpkg-query: no path found matching pattern /etc/alternatives/aptitude dpkg-query: no path found matching pattern /etc/alternatives/aptitude.8.gz dpkg-query: no path found matching pattern /etc/alternatives/aptitude.cs.8.gz dpkg-query: no path found matching pattern /etc/alternatives/aptitude.de.8.gz dpkg-query: no path found matching pattern /etc/alternatives/aptitude.es.8.gz dpkg-query: no path found matching pattern /etc/alternatives/automake dpkg-query: no path found matching pattern /etc/alternatives/automake.1.gz dpkg-query: no path found matching pattern /etc/alternatives/awk ... Upstream's usage is consistent with what update-alternatives(8) implies and what common sense says. In the wiki [1] there's some mention to update-alternatives, and it contains a mention to add `%ghost %_sysconfdir/alternatives/foo`, which can explain why some packages own files there and why some not. If a package owns the symlinks there, IMHO it overcomplicates things, such problems when updating a package, and forgetting to redo `update-alternatives --config`, etc. Also, there's a chance that it didn't use update-alternatives and it did set up the links manually; breaking the mechanism of update-alternatives. As it stands right now, it seems wrong to me. Either we make all links owned by packages or not. I haven't filled any bug yet, since that would need to need a mass bug filling for all the packages that own files in /etc/alternatives/*. I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package. Cheers, Víctor Cuadrado (viccuad) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 11, 2016 at 12:27 PM, Víctor Cuadrado Juan <vcuadradojuan@suse.de> wrote:
Hi everyone!
Problem: Currently the files at /etc/alternatives/* are a mix of files owned by some packages, and not owned by any package: ...
Upstream's usage is consistent with what update-alternatives(8) implies and what common sense says. In the wiki [1] there's some mention to update-alternatives, and it contains a mention to add `%ghost %_sysconfdir/alternatives/foo`, which can explain why some packages own files there and why some not.
If a package owns the symlinks there, IMHO it overcomplicates things, such problems when updating a package, and forgetting to redo `update-alternatives --config`, etc. Also, there's a chance that it didn't use update-alternatives and it did set up the links manually; breaking the mechanism of update-alternatives.
As it stands right now, it seems wrong to me. Either we make all links owned by packages or not.
Installing actual links is definitely wrong.
I haven't filled any bug yet, since that would need to need a mass bug filling for all the packages that own files in /etc/alternatives/*.
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
I think having them %ghost'ed makes sense as it offers additional cleanup possibility on uninstall. I have seen far too many dangling links in /etc/alternatives. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08/11/2016 11:34 AM, Andrei Borzenkov wrote:
I think having them %ghost'ed makes sense as it offers additional cleanup possibility on uninstall. I have seen far too many dangling links in /etc/alternatives.
This indeed seems like the correct way to go. But seems like a patch for when people forget to do `update-alternatives --remove` in %postun or %preun. I wonder if it wouldn't be better to encapsulate the use of update-alternatives by some script, so maintainers don't even have the posibility of forgetting something (AFAIK, this happens in other distros). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory. E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags... Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stephan Kulow schrieb:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
binutils branding-openSUSE ctags emacs ghc gobby gobby04 gtk2 gtk3 java-1_5_0-gcj-compat java-1_7_0-openjdk java-1_7_0-openjdk-bootstrap java-1_8_0-openjdk java-1_9_0-openjdk ksh libdb-4_8 ntfs-3g_ntfsprogs octave PackageKit python3-backports.shutil_get_terminal_size python3-backports.ssl_match_hostname python3-bpython python3-Cython python3-docutils python3-flake8 python3-kde4 python3-lesscpy python3-pep8 python3-pycodestyle python3-pyflakes python3-pyserial python3-tables python3-Twisted python3-unittest2 python3-XlsxWriter python-docutils python-dulwich python-fake-factory python-flake8 python-jmespath python-jsonpatch python-jsonpointer python-kde4 python-lesscpy python-mutagen python-parallax python-pep8 python-pyflakes python-pyserial python-tables python-unittest2 python-virtualenvwrapper python-vobject python-XlsxWriter python-zope.testrunner rarian ruby2.2 ruby2.3 unzip unzip-rcc waf cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 11, 2016 at 5:48 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Stephan Kulow schrieb:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g.
https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
<snip>
ntfs-3g_ntfsprogs <snip>
Can someone who knows more than me (easy in this case), check out: https://build.opensuse.org/request/show/418797 It builds and installs as an upgrade to Leap 42.1 as well as working as a fresh install. Thanks Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
12.08.2016 02:19, Greg Freemyer пишет:
On Thu, Aug 11, 2016 at 5:48 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Stephan Kulow schrieb:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g.
https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
<snip>
ntfs-3g_ntfsprogs <snip>
Can someone who knows more than me (easy in this case), check out:
You need Requires(preun), not Requires(postun) for update-alternatives
It builds and installs as an upgrade to Leap 42.1 as well as working as a fresh install.
Interesting. It looks like %ghost does not actually require existing file in build root indeed. What other package can provide mount.ntfs? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 11, 2016 at 11:41 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
12.08.2016 02:19, Greg Freemyer пишет:
On Thu, Aug 11, 2016 at 5:48 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Stephan Kulow schrieb:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g.
https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
<snip>
ntfs-3g_ntfsprogs <snip>
Can someone who knows more than me (easy in this case), check out:
You need Requires(preun), not Requires(postun) for update-alternatives
Thanks. Updated and SR'ed to factory. https://build.opensuse.org/request/show/419783
It builds and installs as an upgrade to Leap 42.1 as well as working as a fresh install.
Interesting. It looks like %ghost does not actually require existing file in build root indeed.
What other package can provide mount.ntfs?
I don't actually know. I took over maintenance of the package a couple years ago and the update-alternatives logic was already there. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Moin, On Wed, 17 Aug 2016, 18:19:37 +0200, Greg Freemyer wrote:
On Thu, Aug 11, 2016 at 11:41 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote: [...]
What other package can provide mount.ntfs?
I don't actually know. I took over maintenance of the package a couple years ago and the update-alternatives logic was already there.
IIRC, this is probably a left-over from times when ntfs-3g was considered experimental or unstable. Before ntfs-3g became standard, there was an old (mostly) read-only implementation to mount an NTFS file system, which is probably the reason for the usage of alternatives for it.
Greg
Cheers. l8er manfred
On 08/11/2016 11:41 AM, Stephan Kulow wrote:
There is a policy and a rpmlint check for it
Seems the policy is lacking as it is (I point to the mix of symlinks owned and not owned by packages). If you feel like it isn't, please share why you think so and if you think the current state of the symlinks is desirable (that's why I wrote this e-mail :).
- so either you report bugs or fix the packages.
I don't think that starting a mass bug filling for something that hasn't been discussed yet is a solution. I get your point, if you want something to be done, do it yourself. Doing that without consensus or a talk is a recipe for disaster.
There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
Honest question, how did you obtain that information? Do we have infrastructure to see failing rpmlint checks by package? (apart from using a script that you need to remember to run?). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11.08.2016 14:06, Víctor Cuadrado Juan wrote:
On 08/11/2016 11:41 AM, Stephan Kulow wrote:
There is a policy and a rpmlint check for it
Seems the policy is lacking as it is (I point to the mix of symlinks owned and not owned by packages). If you feel like it isn't, please share why you think so and if you think the current state of the symlinks is desirable (that's why I wrote this e-mail :).
No, just some package just don't follow it.
- so either you report bugs or fix the packages.
I don't think that starting a mass bug filling for something that hasn't been discussed yet is a solution.
Aehm, so you want to discuss if those packages not following the policy and have a warning in their rpmlint.log are correct? I don't see why.
I get your point, if you want something to be done, do it yourself. Doing that without consensus or a talk is a recipe for disaster.
There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
Honest question, how did you obtain that information? Do we have infrastructure to see failing rpmlint checks by package? (apart from using a script that you need to remember to run?).
You just replace the package name in the above URL. And your mail already mentioned that ctags is buggy. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08/11/2016 02:08 PM, Stephan Kulow wrote:
On 11.08.2016 14:06, Víctor Cuadrado Juan wrote:
On 08/11/2016 11:41 AM, Stephan Kulow wrote:
There is a policy and a rpmlint check for it
Seems the policy is lacking as it is (I point to the mix of symlinks owned and not owned by packages). If you feel like it isn't, please share why you think so and if you think the current state of the symlinks is desirable (that's why I wrote this e-mail :).
No, just some package just don't follow it.
I see that as a sign of a policy that needs to be improved.
- so either you report bugs or fix the packages.
I don't think that starting a mass bug filling for something that hasn't been discussed yet is a solution.
Aehm, so you want to discuss if those packages not following the policy and have a warning in their rpmlint.log are correct? I don't see why.
Exactly, I want to discuss that. Given that I've been only 2 months working in SUSE, and I come from Debian, where normally a violation of a policy means a package not shipped. I suppose I see it more clear now; policies are suggestions in SUSE. I don't intend to change that. But it's a pity that paid users downstream of openSUSE are suffering from seemingly unrelated bugs for months, because of it (that's what brought me to opening this thread).
Honest question, how did you obtain that information? Do we have infrastructure to see failing rpmlint checks by package? (apart from using a script that you need to remember to run?).
You just replace the package name in the above URL. And your mail already mentioned that ctags is buggy.
But that needs a package name beforehand, I want to obtain a list of those packages: to track progress on the filed bugs, and for the maintainers to learn how different maintainers have fixed the same bug they have in their packages. As other distros do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Víctor Cuadrado Juan schrieb:
On 08/11/2016 02:08 PM, Stephan Kulow wrote:
On 11.08.2016 14:06, Víctor Cuadrado Juan wrote:
On 08/11/2016 11:41 AM, Stephan Kulow wrote:
There is a policy and a rpmlint check for it
Seems the policy is lacking as it is (I point to the mix of symlinks owned and not owned by packages). If you feel like it isn't, please share why you think so and if you think the current state of the symlinks is desirable (that's why I wrote this e-mail :).
No, just some package just don't follow it.
I see that as a sign of a policy that needs to be improved.
- so either you report bugs or fix the packages.
I don't think that starting a mass bug filling for something that hasn't been discussed yet is a solution.
Aehm, so you want to discuss if those packages not following the policy and have a warning in their rpmlint.log are correct? I don't see why.
Exactly, I want to discuss that. Given that I've been only 2 months working in SUSE, and I come from Debian, where normally a violation of a policy means a package not shipped.
I suppose I see it more clear now; policies are suggestions in SUSE. I don't intend to change that. But it's a pity that paid users downstream of openSUSE are suffering from seemingly unrelated bugs for months, because of it (that's what brought me to opening this thread).
IIUC the policy and the check is correct. So this case seems to be just missing follow-up. The usual procedure for a case like this is 1. discuss and approve the policy 2. implement and deploy rpmlint check 3. wait for full distro rebuild to see the rpmlint results 4. file bug reports for all affected packages and set a deadline 5. after the deadline evaluate the packages that didn't get fixed, ie nag maintainer/fix yourself/propose to drop Looks like we came to 3) but didn't continue. Since the problem seems to be important to you and noone else stepped up, feel free to go ahead with 4). I made good experience with filing one tracker bug for $myself that explains what needs to be done and why. Then file bugs for each package that block the tracker bug. Bugzilla tree view gives a good overview of progress then. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08/11/2016 02:41 PM, Ludwig Nussel wrote:
1. discuss and approve the policy 2. implement and deploy rpmlint check 3. wait for full distro rebuild to see the rpmlint results 4. file bug reports for all affected packages and set a deadline 5. after the deadline evaluate the packages that didn't get fixed, ie nag maintainer/fix yourself/propose to drop
Looks like we came to 3) but didn't continue. Since the problem seems to be important to you and noone else stepped up, feel free to go ahead with 4). I made good experience with filing one tracker bug for $myself that explains what needs to be done and why. Then file bugs for each package that block the tracker bug. Bugzilla tree view gives a good overview of progress then.
Many thanks for the thorough explanation :). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests. Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint. The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86 _64/ctags/rpmlint.log
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests.
Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint.
The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find.
Today I just fixed gtk2 and gtk3, the submissions are: https://build.opensuse.org/request/show/418653 https://build.opensuse.org/request/show/418655 Maybe they serve as indication what was wrong and what is right now AS for the documentation https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines is the one giving most hints imho Cheers, Dominique
On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86 _64/ctags/rpmlint.log
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests.
Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint.
The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find.
Today I just fixed gtk2 and gtk3, the submissions are: https://build.opensuse.org/request/show/418653 https://build.opensuse.org/request/show/418655 Maybe they serve as indication what was wrong and what is right now
AS for the documentation https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines is the one giving most hints imho
Cheers, Dominique
Maybe it would be better if I chose an example and explain my source of confusion. python3-Cython is the example I have been using for other packages, because previously it worked fine with no rpmlint warnings: https://build.opensuse.org/package/show/devel:languages:python3/python3-Cyth... Let's look at the current warnings: python3-Cython.x86_64: W: suse-alternative-link-missing /etc/alternatives/" The file %{_sysconfdir}/alternatives/$(basename generic-name) is missing in the file list. Mark it as %ghost and add it to the file list. python3-Cython.x86_64: W: suse-alternative-generic-name-missing " The update-alternatives generic name is not in the filelist. Create it as a symlink to %{_sysconfdir}/alternatives/$(basename generic-name) and add it to the file list. But if you look at the files list, that seems to be exactly what is being done: %{_bindir}/cygdb %{_bindir}/cython %{_bindir}/cythonize %{_bindir}/cygdb-%{py3_ver} %{_bindir}/cython-%{py3_ver} %{_bindir}/cythonize-%{py3_ver} %ghost %{_sysconfdir}/alternatives/cygdb %ghost %{_sysconfdir}/alternatives/cython %ghost %{_sysconfdir}/alternatives/cythonize So from the rpmlint warnings I don't know where the policy is being violated. Although I am not sure what "$(basename generic-name)" is supposed to be, are the names being used in "%{_sysconfdir}/alternatives/" wrong? It is hard to tell from the example on the wiki since I don't know what files in the example are "real" files and which ones are created by update-alternatives. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
11.08.2016 18:53, Todd Rme пишет:
On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86 _64/ctags/rpmlint.log
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests.
Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint.
The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find.
Today I just fixed gtk2 and gtk3, the submissions are: https://build.opensuse.org/request/show/418653 https://build.opensuse.org/request/show/418655 Maybe they serve as indication what was wrong and what is right now
AS for the documentation https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines is the one giving most hints imho
Cheers, Dominique
Maybe it would be better if I chose an example and explain my source of confusion. python3-Cython is the example I have been using for other packages, because previously it worked fine with no rpmlint warnings: https://build.opensuse.org/package/show/devel:languages:python3/python3-Cyth...
update-alternatives --remove should be in %preun, not in %postun
Let's look at the current warnings:
python3-Cython.x86_64: W: suse-alternative-link-missing /etc/alternatives/" The file %{_sysconfdir}/alternatives/$(basename generic-name) is missing in the file list. Mark it as %ghost and add it to the file list.
Somehow it fails to parse script. My hunch is, quotes around update-alternatives invocation ("%_sbindir/update-alternatives") confuse it. They are not needed anyway - try to remove them.
python3-Cython.x86_64: W: suse-alternative-generic-name-missing " The update-alternatives generic name is not in the filelist. Create it as a symlink to %{_sysconfdir}/alternatives/$(basename generic-name) and add it to the file list.
But if you look at the files list, that seems to be exactly what is being done:
%{_bindir}/cygdb %{_bindir}/cython %{_bindir}/cythonize %{_bindir}/cygdb-%{py3_ver} %{_bindir}/cython-%{py3_ver} %{_bindir}/cythonize-%{py3_ver} %ghost %{_sysconfdir}/alternatives/cygdb %ghost %{_sysconfdir}/alternatives/cython %ghost %{_sysconfdir}/alternatives/cythonize
So from the rpmlint warnings I don't know where the policy is being violated. Although I am not sure what "$(basename generic-name)" is supposed to be, are the names being used in "%{_sysconfdir}/alternatives/" wrong? It is hard to tell from the example on the wiki since I don't know what files in the example are "real" files and which ones are created by update-alternatives.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 11, 2016 at 2:15 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
11.08.2016 18:53, Todd Rme пишет:
On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86 _64/ctags/rpmlint.log
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests.
Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint.
The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find.
Today I just fixed gtk2 and gtk3, the submissions are: https://build.opensuse.org/request/show/418653 https://build.opensuse.org/request/show/418655 Maybe they serve as indication what was wrong and what is right now
AS for the documentation https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines is the one giving most hints imho
Cheers, Dominique
Maybe it would be better if I chose an example and explain my source of confusion. python3-Cython is the example I have been using for other packages, because previously it worked fine with no rpmlint warnings: https://build.opensuse.org/package/show/devel:languages:python3/python3-Cyth...
update-alternatives --remove should be in %preun, not in %postun
Okay.
Let's look at the current warnings:
python3-Cython.x86_64: W: suse-alternative-link-missing /etc/alternatives/" The file %{_sysconfdir}/alternatives/$(basename generic-name) is missing in the file list. Mark it as %ghost and add it to the file list.
Somehow it fails to parse script. My hunch is, quotes around update-alternatives invocation ("%_sbindir/update-alternatives") confuse it. They are not needed anyway - try to remove them.
That seems to have fixed the problem, thanks. This is the sort of thing more documentation for update-alternatives on the wiki could help with.
python3-Cython.x86_64: W: suse-alternative-generic-name-missing " The update-alternatives generic name is not in the filelist. Create it as a symlink to %{_sysconfdir}/alternatives/$(basename generic-name) and add it to the file list.
But if you look at the files list, that seems to be exactly what is being done:
%{_bindir}/cygdb %{_bindir}/cython %{_bindir}/cythonize %{_bindir}/cygdb-%{py3_ver} %{_bindir}/cython-%{py3_ver} %{_bindir}/cythonize-%{py3_ver} %ghost %{_sysconfdir}/alternatives/cygdb %ghost %{_sysconfdir}/alternatives/cython %ghost %{_sysconfdir}/alternatives/cythonize
So from the rpmlint warnings I don't know where the policy is being violated. Although I am not sure what "$(basename generic-name)" is supposed to be, are the names being used in "%{_sysconfdir}/alternatives/" wrong? It is hard to tell from the example on the wiki since I don't know what files in the example are "real" files and which ones are created by update-alternatives.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86 _64/ctags/rpmlint.log
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests.
Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint.
The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find.
Today I just fixed gtk2 and gtk3, the submissions are: https://build.opensuse.org/request/show/418653 https://build.opensuse.org/request/show/418655 Maybe they serve as indication what was wrong and what is right now
AS for the documentation https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines is the one giving most hints imho
Cheers, Dominique
I'm totally new to alternatives, but ... In the install section of the wiki page I see: ===== %install # create a dummy target for /etc/alternatives/vim mkdir -p %{buildroot}%{_sysconfdir}/alternatives ln -s -f %{_sysconfdir}/alternatives/vim %{buildroot}%{_bindir}/vim ===== Isn't that missing %{buildroot} in the first arg of the link statement? If not, what does the mkdir line have it? If correct as is, it seems a comment is appropriate. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 11, 2016 at 6:09 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86 _64/ctags/rpmlint.log
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests.
Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint.
The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find.
Today I just fixed gtk2 and gtk3, the submissions are: https://build.opensuse.org/request/show/418653 https://build.opensuse.org/request/show/418655 Maybe they serve as indication what was wrong and what is right now
AS for the documentation https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines is the one giving most hints imho
Cheers, Dominique
I'm totally new to alternatives, but ...
In the install section of the wiki page I see:
===== %install # create a dummy target for /etc/alternatives/vim mkdir -p %{buildroot}%{_sysconfdir}/alternatives ln -s -f %{_sysconfdir}/alternatives/vim %{buildroot}%{_bindir}/vim =====
Isn't that missing %{buildroot} in the first arg of the link statement?
If not, what does the mkdir line have it?
If correct as is, it seems a comment is appropriate.
Greg
Another question about the wiki example: === %postun if [ "$1" = 0 ] ; then update-alternatives --remove vim %{_bindir}/vim-normal fi %preun enhanced if [ "$1" = 0 ] ; then update-alternatives --remove vim %{_bindir}/vim-enhanced fi === Shouldn't they both be postun or preun? If not, a comment in the example as to why the choice would be good. Thanks Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
12.08.2016 01:54, Greg Freemyer пишет:
On Thu, Aug 11, 2016 at 6:09 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar I'm totally new to alternatives, but ...
In the install section of the wiki page I see:
===== %install # create a dummy target for /etc/alternatives/vim mkdir -p %{buildroot}%{_sysconfdir}/alternatives ln -s -f %{_sysconfdir}/alternatives/vim %{buildroot}%{_bindir}/vim =====
Isn't that missing %{buildroot} in the first arg of the link statement?
No. It is target of symlink as it will appear on installed system.
If not, what does the mkdir line have it?
One step is missing in example - creating (empty) file for %ghost to work - %{buildroot}%{_sysconfdir}/alternatives/vim. This should obviously happen under buildroot.
If correct as is, it seems a comment is appropriate.
Greg
Another question about the wiki example:
=== %postun if [ "$1" = 0 ] ; then update-alternatives --remove vim %{_bindir}/vim-normal fi
%preun enhanced if [ "$1" = 0 ] ; then update-alternatives --remove vim %{_bindir}/vim-enhanced fi ===
Shouldn't they both be postun or preun?
No. As a general rule you cleanup package *before* you remove it. In particular, running in %postun all files are already removed, I'm not sure what update-alternatives does in this case.
If not, a comment in the example as to why the choice would be good.
What I am unsure - I was under impression that link target is managed by update-alternatives too, i.e. in this case /usr/bin/vim is created by update-alternatives --install. In this case it probably has to be %ghost as well. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12.08.2016 05:30, Andrei Borzenkov wrote:
One step is missing in example - creating (empty) file for %ghost to work - %{buildroot}%{_sysconfdir}/alternatives/vim. This should obviously happen under buildroot.
You only need this in ancient rpm versions.
What I am unsure - I was under impression that link target is managed by update-alternatives too, i.e. in this case /usr/bin/vim is created by update-alternatives --install. In this case it probably has to be %ghost as well.
No, /usr/bin/vim is a link to /etc/alternatives is a link shared in all packages owning vim. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Aug 12, 2016 at 11:53 AM, Stephan Kulow <coolo@suse.de> wrote:
On 12.08.2016 05:30, Andrei Borzenkov wrote:
One step is missing in example - creating (empty) file for %ghost to work - %{buildroot}%{_sysconfdir}/alternatives/vim. This should obviously happen under buildroot.
You only need this in ancient rpm versions.
Why do we need to create directory then?
What I am unsure - I was under impression that link target is managed by update-alternatives too, i.e. in this case /usr/bin/vim is created by update-alternatives --install. In this case it probably has to be %ghost as well.
No, /usr/bin/vim is a link to /etc/alternatives is a link shared in all packages owning vim.
Yes, I understand that, but what I mean - update-alternatives --install will create /usr/bin/vim as link to /etc/alternatives/vim anyway. So is it necessary to ship it in package at all? This simplifies packaging by removing one more step. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12.08.2016 11:47, Andrei Borzenkov wrote:
On Fri, Aug 12, 2016 at 11:53 AM, Stephan Kulow <coolo@suse.de> wrote:
On 12.08.2016 05:30, Andrei Borzenkov wrote:
One step is missing in example - creating (empty) file for %ghost to work - %{buildroot}%{_sysconfdir}/alternatives/vim. This should obviously happen under buildroot.
You only need this in ancient rpm versions.
Why do we need to create directory then?
What I am unsure - I was under impression that link target is managed by update-alternatives too, i.e. in this case /usr/bin/vim is created by update-alternatives --install. In this case it probably has to be %ghost as well.
No, /usr/bin/vim is a link to /etc/alternatives is a link shared in all packages owning vim.
Yes, I understand that, but what I mean - update-alternatives --install will create /usr/bin/vim as link to /etc/alternatives/vim anyway. So is it necessary to ship it in package at all? This simplifies packaging by removing one more step.
This verifies that we don't have packages that package /usr/bin/vim *not* linking to /etc/alternatives - as you would get a file conflict. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11.08.2016 17:32, Todd Rme wrote:
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests.
Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint.
The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find.
See https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 11, 2016 at 11:37 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 17:32, Todd Rme wrote:
On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo@suse.de> wrote:
On 11.08.2016 11:27, Víctor Cuadrado Juan wrote:
Hi everyone!
I would love to gather some ideas and consensus on this, and ideally, get a policy on how update-alternatives should be used, and have an rpmlint check written/improved so we can start filling bugs per package.
There is a policy and a rpmlint check for it - so either you report bugs or fix the packages. There are 61 packages atm hitting this error in Factory.
E.g. https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/ctags...
Greetings, Stephan
Where is the policy documented? I can't find it. There is an rpmlint warning, but it is unclear from the warning how to fix it, since the packages seem to be doing what the warning requests.
Perhaps it might be helpful to pick an example package that is violating the policy and explain exactly what needs to be changed to make it complaint.
The whole update-alternatives system is pretty cryptic and almost totally undocumented in the openSUSE wiki from what I have been able to find.
See https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines
Greetings, Stephan
I don't see a policy there, or even an explanation of how to use update-alternatives. I see an explanation of what update-alternatives does (but not how to use it), and one example of its use with no explanation. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Andrei Borzenkov -
Dominique Leuenberger / DimStar -
Greg Freemyer -
Ludwig Nussel -
Manfred Hollstein -
Stephan Kulow -
Todd Rme -
Víctor Cuadrado Juan