Re: Renaming binaries due to conflicts (was: Finding conflicts in /usr/bin)

[Neal Gompa]

On Wed, May 17, 2017 at 1:01 PM, Mattia Verga  wrote:
> Debian guys use a README.debian file distributed with the package to provide
> end user a notice about any change in standard binary names due to
> conflicts.
>
> Do we have something similar in Fedora? What about a wiki page where to
> provide this kind of information? Something like this test page :
> https://fedoraproject.org/wiki/User:Mattia/renamedBinariesList
>
> Do you think it worths to present this proposal to FESCo?

As a matter of convention, I've seen people use README.fedora or
README.distro or variations of that with the package name prefixed to
that, but we don't have anything particularly specific, largely
because we don't have a mechanism to force people to read those
things.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Renaming binaries due to conflicts (was: Finding conflicts in /usr/bin)

[Mattia Verga]

Debian guys use a README.debian file distributed with the package to 
provide end user a notice about any change in standard binary names due 
to conflicts.


Do we have something similar in Fedora? What about a wiki page where to 
provide this kind of information? Something like this test page :  
https://fedoraproject.org/wiki/User:Mattia/renamedBinariesList


Do you think it worths to present this proposal to FESCo?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Rex Dieter]

Przemek Klosowski wrote:

>>> While this should probably be considered a bug that needs to be fixed,
>> https://bugzilla.redhat.com/show_bug.cgi?id=1451463
> And Frank Ch. Eigler closed it, explaining that:
>> It turns out that this is a deliberate decision.  As
>> outlined within the .spec file, the -devel subrpm is for building
>> systemtap modules (running pass 1..4); the -client subrpm is for being
>> able to build
>> systemtap modules -remotely-.  Both those tasks happen to be performed by
>> the same binary.
> One could create a sub-subpackage that both subpackages depend on, but
> it's getting to be silly. Is there no other option to handle this in RPM?

other option is the status quo, where a common file is shared among > 1 
subpkg (which is acceptable, not particularly a bug per-se).

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Przemek Klosowski]

On 05/16/2017 01:14 PM, Przemek Klosowski wrote:


This sender failed our fraud detection checks and may not be who they appear to be. 
Learn about spoofing    Feedback 


On 05/13/2017 02:55 AM, Emmanuel Seyman wrote:

* Przemek Klosowski [12/05/2017 16:27] :

The only one I could see that is really provided by multiple packages is
/usr/bin/stap* : they seem to be provided by both systemtap-client and
systemtap-devel.
WHAT'S UP WITH THAT?

While this should probably be considered a bug that needs to be fixed,

https://bugzilla.redhat.com/show_bug.cgi?id=1451463

And Frank Ch. Eigler closed it, explaining that:

It turns out that this is a deliberate decision.  As
outlined within the .spec file, the -devel subrpm is for building systemtap
modules (running pass 1..4); the -client subrpm is for being able to build
systemtap modules -remotely-.  Both those tasks happen to be performed by the
same binary.
One could create a sub-subpackage that both subpackages depend on, but 
it's getting to be silly. Is there no other option to handle this in RPM?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Przemek Klosowski]

On 05/13/2017 02:55 AM, Emmanuel Seyman wrote:

* Przemek Klosowski [12/05/2017 16:27] :

The only one I could see that is really provided by multiple packages is
/usr/bin/stap* : they seem to be provided by both systemtap-client and
systemtap-devel.
WHAT'S UP WITH THAT?

While this should probably be considered a bug that needs to be fixed,

https://bugzilla.redhat.com/show_bug.cgi?id=1451463

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Emmanuel Seyman]

* Przemek Klosowski [12/05/2017 16:27] :
>
> The only one I could see that is really provided by multiple packages is
> /usr/bin/stap* : they seem to be provided by both systemtap-client and
> systemtap-devel.
> WHAT'S UP WITH THAT?

While this should probably be considered a bug that needs to be fixed,
this is a different situation that the one OP is in. Here, the binaries
supplied by both packages are identical and do not conflict with each
other.

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Przemek Klosowski]

On 05/12/2017 02:50 PM, Mattia Verga wrote:
After a recent bug report I've received [1] I thought to conduct a 
survey on all packages available in Fedora to find conflicts between 
binary names under /usr/bin but I don't know how exactly do that. Is 
there a way to extract the list of all files installed under /usr/bin 
from all packages?
I tried with 'dnf repoquery --disablerepo="updates" -l *.x86_64 | grep 
"/usr/bin" &> filelist.txt' but it seems to only list files for 
packages I've installed on my system.
My suspect is that this survey will result in many packages are using 
the same very common binary names.
Ugly way: dnf whatprovides '/usr/bin/*'  gives a list of packages that 
needs some postprocessing. This reports 554 packages.

Next we do
   for a in `cat /tmp/y` ; do dnf repoquery $a -l | grep /usr/bin; done
which results in 1210 files installed in /usr/bin/, of which 137 seem to 
be 2,3 or 4-plicates.


The situation isn't quite bad, though, because packages are offered for 
different archs and updates:


$ dnf whatprovides /usr/bin/gio
...
glib2-2.50.3-1.fc25.x86_64 : A library of handy utility functions
Repo: @System
glib2-2.50.3-1.fc25.i686 : A library of handy utility functions 
Repo: @System
glib2-2.50.1-1.fc25.i686 : A library of handy utility functions 
Repo: fedora
glib2-2.50.1-1.fc25.x86_64 : A library of handy utility functions 
Repo: fedora
glib2-2.50.3-1.fc25.i686 : A library of handy utility functions 
Repo: updates
glib2-2.50.3-1.fc25.x86_64 : A library of handy utility functions 
Repo: updates


The only one I could see that is really provided by multiple packages is 
/usr/bin/stap* : they seem to be provided by both systemtap-client and 
systemtap-devel.

WHAT'S UP WITH THAT?

There's also /usr/bin/mailq, but it's legit because it uses 'alternatives':

postfix-2:3.1.4-1.fc25.x86_64 : Postfix Mail Transport Agent
esmtp-1.2-5.fc25.x86_64 : User configurable send-only Mail Transfer Agent
postfix-2:3.1.4-1.fc25.x86_64 : Postfix Mail Transport Agent
sendmail-8.15.2-8.fc25.x86_64 : A widely used Mail Transport Agent (MTA)
esmtp-1.2-4.fc25.x86_64 : User configurable send-only Mail Transfer Agent
exim-4.87-5.fc25.x86_64 : The exim mail transfer agent
opensmtpd-6.0.2p1-1.fc25.x86_64 : Free implementation of the server-side 
SMTP

postfix-2:3.1.3-1.fc25.x86_64 : Postfix Mail Transport Agent
sendmail-8.15.2-7.fc25.x86_64 : A widely used Mail Transport Agent (MTA)
ssmtp-2.64-16.fc24.x86_64 : Extremely simple MTA to get mail off the 
system to a



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Rafal Luzynski]

12.05.2017 20:50 Mattia Verga  wrote:
> [...]
> I tried with 'dnf repoquery --disablerepo="updates" -l *.x86_64 | grep
> "/usr/bin" &> filelist.txt' but it seems to only list files for packages
> I've installed on my system.

I tried:

dnf repoquery --disablerepo=updates -l \*.x86_64 ...

and it seems to have worked. You need a backslash before an asterisk,
otherwise it is substituted with *.x86_64 files from your current
directory.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Emmanuel Seyman]

* Mattia Verga [12/05/2017 20:50] :
>
>  Is there a way to
> extract the list of all files installed under /usr/bin from all packages?

Yum/dnf repositories have a filelists.xml.gz file in their metadata that
contains the list of files in certain directories (/usr/bin is one of them).

You can download that and run :
zgrep '/usr/bin/' $FILELISTS | sed -e 's#  ##' -e 's###'

and get the list of every file in /usr/bin .

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Finding conflicts in /usr/bin

[Mattia Verga]

After a recent bug report I've received [1] I thought to conduct a 
survey on all packages available in Fedora to find conflicts between 
binary names under /usr/bin but I don't know how exactly do that. Is 
there a way to extract the list of all files installed under /usr/bin 
from all packages?
I tried with 'dnf repoquery --disablerepo="updates" -l *.x86_64 | grep 
"/usr/bin" &> filelist.txt' but it seems to only list files for packages 
I've installed on my system.
My suspect is that this survey will result in many packages are using 
the same very common binary names.


I would like also to discuss the proposal to have a check in the rpm 
build process on filenames that get installed under /usr/bin. This would 
prevent these type of conflicts.
Maybe this can be allowed in very special cases with the usage of a mark 
in file section, just like we do with %config.

What's your opinion?

Mattia

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1450190
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org