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

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

12.08.2016 02:19, Greg Freemyer пишет:

On Thu, Aug 11, 2016 at 5:48 AM, Ludwig Nussel 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

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

Moin, On Wed, 17 Aug 2016, 18:19:37 +0200, Greg Freemyer wrote:

On Thu, Aug 11, 2016 at 11:41 PM, Andrei Borzenkov 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 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

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 Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow 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, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar wrote:

On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:

...

On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow 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

On Thu, Aug 11, 2016 at 2:15 PM, Andrei Borzenkov wrote:

11.08.2016 18:53, Todd Rme пишет:

...

On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar wrote:

...

On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:

...

On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow 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 6:09 PM, Greg Freemyer wrote:

On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar wrote:

...

On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote:

...

On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow 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

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 12.08.2016 11:47, Andrei Borzenkov wrote:

On Fri, Aug 12, 2016 at 11:53 AM, Stephan Kulow 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 Thu, Aug 11, 2016 at 11:37 AM, Stephan Kulow wrote:

On 11.08.2016 17:32, Todd Rme wrote:

...

On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow 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