Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fuse-smb - FUSE-Filesystem to fast and easy access remote resources via SMB https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222742 ------- Additional Comments From mszpak@xxxxx 2007-01-16 17:18 EST ------- (In reply to comment #2) (...) > * you're using versioned dependecies unnecesarily. Also, some of them have to > be removed completely. > Have a look at fuse-smb-0.8.5-2.fc7.x86_64.rpm requires list. It requires > libfuse.so.2 which is owned by fuse-libs and libsmbclient.so.0 owned by samba- > common. It means you don't need samba-common and fuse-libs dependencies. Also, > you can smoothly get rid of fuse dependency. You don't need versioned > dependency for fuse-devel as well. At first I agree with you that few of them can smoothly removed, but let me explain one thing. The main reason why I use (sometimes redundant) full packages name is the fact that those packages are also (till now only) avilable as a separate packages from my website. When I download some stand-alone package and try to install it it's much more readable to see "fuse-lib > 2.3 is required by ..." than "libfuse.so.2()(64bit) is required by ...". In the first option I know what should I install, in the second I have to find it out first [1]. [1] - I know that novadays (in FC4+ out-of-box?) it's possible to use yum to resolve dependencies and install required packages. The only problem I see is the situation when package was renamed in a newer version, but SPEC file should be then updated. Do you really think that using full package names in the Requirement section instead of letting RPM do it, can cause some problems or is an out-of-date habit? (In reply to comment #3) > Setting CFLAGS here is superfluous True. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review