Followup to FESCO meeting: firefox dependancy tracking.

[Christopher Aillon]

Let me first preface this by stating very clearly: Firefox is NOT a 
devel environment.  It will NEVER be one.  There is a -devel package 
only because there is no other choice at the moment.  There is no 
supported way to use a gecko build environment from upstream until 
XULrunner 1.0 is released.  Every package that attempts to build against 
Firefox is doing so at their own risk.

Having said that, every package in Core which needs to has always had an 
explicit versioned requires (except for the packages in FC6 GOLD which 
was an unfortunate regression, but long since fixed).  See the latest 
epiphany/devhelp/yelp RPMs for how to do the dependencies (I'm not sure 
how they got in your list of non-versioned deps unless you looked at FC6 
GOLD).

So, the real question is now: do we want to continue to allow more gecko 
based applications into fedora at all?  There is no real build 
environment for it, and it works only as a side effect of hacking it up 
to work for yelp, really which we need and is in core.  I'd like to say 
no if we can help it.  Things like esc have no business using gecko, 
IMO.  Using gecko just opens up the package maintainer to a world of 
pain, which I also have to face, but I'm being paid for it at least.  It 
is a negative experience for the maintainer to have to rebuild things 
all the damn time.



On 01/05/2007 02:17 AM, Jeff Spaleta wrote:
> As per the FESCO meeting item list, and irc discussion, here is my
> humble attempt to identify via repoquery what packages are currently
> prone to library dependancy breakage without being noticed by the
> automated scripts which just look for rpm autogenerated library
> dependancies.
> 
> these are packages which have a requirement on a library from firefox,
> but do not explicitly require firefox or gecko-libs:
> 
> epiphany-extensions-0:2.16.1-1.i386
> gnome-chemistry-utils-mozplugin-0:0.6.3-4.fc6.i386
> openvrml-gtkplug-0:0.16.3-1.fc6.i386
> openvrml-mozilla-plugin-0:0.16.3-1.fc6.i386
> 
> If you just look at packages which do not use a versioned firefox dep
> you also get:
> 
> devhelp-0:0.12-9.fc6.i386
> epiphany-0:2.16.2-1.fc6.i386
> galeon-0:2.0.3-4.fc6.1.i386
> gtkmozembedmm-0:1.4.2.cvs20060817-7.fc6.i386
> libswt3-gtk2-1:3.2.1-23.fc6.i386
> openvrml-0:0.16.3-1.fc6.i386
> yelp-0:2.16.0-11.fc6.i386
> 
> 
> The only packages which use a versioned firefox requirements are:
> 
> gnome-python2-gtkmozembed-0:2.14.2-6.fc6.i386
> liferea-0:1.0.26-2.fc6.i386
> 
> My suggestion is that all packages which end up requiring a library
> from firefox should use a versioned dependancy as long as firefox
> continues to keep its libraries in a versioned directory tree (
> currently  /usr/lib/firefox-1.5.0.9/ ). If a versioned firefox
> requirement is used we can atleast become aware of breakage as it
> happens via the available infrastructure scripts. As it stands the
> majority of the packages which depend on libraries from firefox will
> have library breakages on firefox updates and we can't see them from
> the available rpm dependancy information. Users will hit this issues
> when the library linker goes looking for a library in the wrong place.
> 
> Comments?  Should I start filing bugs against these packages to get
> versioned firefox requires added to their specfiles?  Should we look
> at making this sort of thing part of the review process that should be
> checked for?
> 
> Note that my use of repoquery still doesn't catch problematic packages
> like gnome-python2-extras nor esc which do not have trackable rpm
> library dependancies for repoquery to work with.
> 
> -jef
> 
> -- 
> Fedora-maintainers mailing list
> Fedora-maintainers at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-maintainers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20070105/1c8362d5/attachment.bin>