%pre: fedora-packaging@redhat.com CCed, reply-to set to fedora-extras-list@redhat.com -- I suspects mailman will eat it; please simply reply to fedora-extras-list manually to avoid further crossposting and slitted discussions; tia!
Hi,
skvidal mentioned in #fedora-extras we should consider going through all packages and look out for unnecessary file deps outside of "/etc /usr/sbin/ /usr/bin/ /sbin/ /bin/". Those are covered by the primary dataset yum loads normally. Yum has do load a second, (often big) file to depsolve the others; that often slows down depsolving packages a lot -- most of us were probably bitten by this already in the past and know what I'm talking about.
So, should we try to get rid of such deps as much as possible? And maybe even put a short note into the packaging guidelines that file based deps outside of "/etc {/usr,}/{s,}bin/" slow down yum and therefore should be avoided if possible?
Options?
BTW, I did a quick lookup on a x86-64 FC-6 machine with repoquery; we seems to have 32 file based deps outside of "/etc {/usr,}/{s,}bin/" in Extras:
/usr/lib64/ctapi /usr/lib64/libpcsclite.so.1 /usr/lib64/pgsql /usr/share/pgsql /usr/include/linux /usr/lib64/util-vserver /usr/share/fonts/bitstream-vera/Vera.ttf /usr/share/themes /var/www/cgi-bin /var/www/html /usr/lib64/pkgconfig /usr/share/X11/app-defaults /usr/lib64/php/modules /usr/share/icons/hicolor/scalable /usr/lib64/mozilla/plugins /usr/share/xml /usr/lib/python2.4/site-packages /usr/include/sysfs/libsysfs.h /usr/lib64/mozilla/plugins /usr/lib64/util-vserver /usr/share/sgml/html/4.01 /usr/share/sgml/xhtml1/xhtml1-20020801/DTD /usr/share/X11/rgb.txt /usr/share/aclocal /usr/lib64/pkgconfig /usr/share/desktop-menu-patches/redhat-audio-player.desktop /usr/lib64/ctapi /usr/share/emacs/site-lisp /usr/share/fonts /usr/lib64/util-vserver /usr/lib64/util-vserver/sigexec /usr/share/basemap
At least some of them look suspicious: /usr/lib/python2.4/site-packages -> simply python
/usr/lib64/util-vserver -> simply util-vserver-core
/usr/lib64/ctapi -> simply ctapi-common
/usr/lib64/pkgconfig -> simply pkgconfig
...
/usr/lib64/mozilla/plugins and some other dirs are probaly okay.
CU thl
P.S.:Core has some more: /usr/lib64/python2.4 /usr/lib/news/lib/innshellvars.pl /usr/lib64/python2.4 /usr/lib/libgcj.so.7rh /usr/lib/libz.so /usr/lib64/python2.4 /usr/lib64/libstdc++.so.6 /usr/share/openldap/migration/migrate_common.ph /usr/lib/libstdc++.so.6 /usr/lib/lsb/install_initd /usr/lib/lsb/remove_initd /usr/lib64/libgcj.so.7rh /usr/lib64/libz.so /usr/share/magic.mime /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/python2.4 /lib64/security/pam_loginuid.so /usr/lib64/python2.4/site-packages /usr/share/gnome-screensaver/lock-dialog-system.glade /usr/share/desktop-menu-patches/gnome-gdmsetup.desktop /lib64/security/pam_loginuid.so
On Wed, Dec 13, 2006 at 06:00:38PM +0100, Thorsten Leemhuis wrote:
%pre: fedora-packaging@redhat.com CCed, reply-to set to fedora-extras-list@redhat.com -- I suspects mailman will eat it; please simply reply to fedora-extras-list manually to avoid further crossposting and slitted discussions; tia!
mailman seems to do fine ;)
skvidal mentioned in #fedora-extras we should consider going through all packages and look out for unnecessary file deps outside of "/etc /usr/sbin/ /usr/bin/ /sbin/ /bin/". Those are covered by the primary dataset yum loads normally. Yum has do load a second, (often big) file to depsolve the others; that often slows down depsolving packages a lot -- most of us were probably bitten by this already in the past and know what I'm talking about.
So, should we try to get rid of such deps as much as possible? And maybe even put a short note into the packaging guidelines that file based deps outside of "/etc {/usr,}/{s,}bin/" slow down yum and therefore should be avoided if possible?
Options?
In the packaging guidelines I'd rather argue that *manual* file based dependencies should only be used if there is really a reason to, including bin/sysconfigdirs.
Possible reasons can be:
o portability between releases (package renames/splits) o poor man's arch dependencies, e.g. depending on /usr/lib/python2.4 will make sure python.i386 will be pulled in on x86_64. o are there any others?
Sometimes the first item is abused "in advance", e.g. for initscripts or kernel-utils which contain(ed) stuff that developers felt they may get split into another package, even if they didn't at that time.
Axel Thimm schrieb:
On Wed, Dec 13, 2006 at 06:00:38PM +0100, Thorsten Leemhuis wrote:
%pre: fedora-packaging@redhat.com CCed, reply-to set to fedora-extras-list@redhat.com -- I suspects mailman will eat it; please simply reply to fedora-extras-list manually to avoid further crossposting and slitted discussions; tia!
mailman seems to do fine ;)
No, it eat it, as the post on fedora-packaging@redhat.com would have had set "Reply-to: fedora-extras-list@redhat.com"
Anyway, we discussed this topic in the FESCo meeting last Thursday. The result was:
It's job of the packaging committee to codify some rules around this and FESCo's job will be to implement them afterwards.
rdieter promised to bring it up the packaging committee, so all further discussion should be held on fedora-packaging@redhat.com to avoid confusion.
Cu thl
packaging@lists.fedoraproject.org