[Fedora-packaging] dangling symlink vs file dependencies

Fri Jul 3 12:13:44 UTC 2015

$ sudo dnf --enablerepo=* clean all
Cleaning repos: rpmfusion-nonfree-updates-testing updates-debuginfo
              : rawhide-source vondruch-doublecmd
rpmfusion-free-updates-testing
              : updates-testing rpmfusion-nonfree-updates-testing-source
              : rpmfusion-nonfree-debuginfo updates-testing-source
              : rpmfusion-free-rawhide-debuginfo bluejeans
              : rpmfusion-nonfree-rawhide-debuginfo
              : rpmfusion-nonfree-updates-source
rpmfusion-free-rawhide-source
              : fedora rpmfusion-free-source beaker-client-testing
              : rpmfusion-free-updates-testing-debuginfo
              : rpmfusion-nonfree-updates-debuginfo updates-source
              : rpmfusion-free-rawhide rpmfusion-free-updates
adobe-linux-x86_64
              : rpmfusion-nonfree-updates rpmfusion-free rhpkg
rawhide-debuginfo
              : rpmfusion-nonfree-source fedora-debuginfo
              : rpmfusion-nonfree-rawhide rpmfusion-free-updates-source
              : updates-testing-debuginfo
rpmfusion-free-updates-testing-source
              : rawhide fedora-source
              : rpmfusion-nonfree-updates-testing-debuginfo
              : rpmfusion-nonfree-rawhide-source rpmfusion-nonfree
              : rpmfusion-free-debuginfo
rpmfusion-free-updates-debuginfo brew
              : beaker-client updates
Cleaning up Everything

$ find /var/cache/dnf/x86_64/22/ -name \*filelist\*

$ sudo dnf update
Failed to synchronize cache for repo 'vondruch-doublecmd' from
'http://copr-be.cloud.fedoraproject.org/results/vondruch/doublecmd/fedora-22-x86_64/':
Cannot download repomd.xml: Cannot download repodata/repomd.xml: All
mirrors were tried, disabling.
Blue Jeans Network, Inc. - x86_64 software and   28 kB/s |  18 kB    
00:00   
Fedora 22 - x86_64                              4.7 MB/s |  41 MB    
00:08   
RPM Fusion for Fedora 22 - Free - Updates       3.9 kB/s | 399  B    
00:00   
Adobe Systems Incorporated                      8.8 kB/s | 1.8 kB    
00:00   
RPM Fusion for Fedora 22 - Nonfree - Updates    4.2 kB/s | 399  B    
00:00   
RPM Fusion for Fedora 22 - Free                 2.1 MB/s | 549 kB    
00:00   
rhpkg for Fedora 22                              13 kB/s | 7.0 kB    
00:00   
RPM Fusion for Fedora 22 - Nonfree              995 kB/s | 150 kB    
00:00   
Brew Buildsystem for Fedora 22 - x86_64         9.8 kB/s | 5.0 kB    
00:00   
Beaker Client - Fedora22                         33 kB/s |  26 kB    
00:00   
Fedora 22 - x86_64 - Updates                    4.5 MB/s | 9.9 MB    
00:02   
Last metadata expiration check performed 0:00:03 ago on Fri Jul  3
14:02:43 2015.
Dependencies resolved.
Nothing to do.
Complete!

$ find /var/cache/dnf/x86_64/22/ -name \*filelist\*
/var/cache/dnf/x86_64/22/bluejeans/repodata/f48d34ecc3ab5fe66c21fff01160a05926b1a61b079c3915bba224de25939baa-filelists.xml.gz
/var/cache/dnf/x86_64/22/rpmfusion-free-updates/repodata/filelists.xml.gz
/var/cache/dnf/x86_64/22/fedora/repodata/080ae53f869b62ca5a4bdc71c930936863c5d72d52eab7252a58f78930b84756-filelists.xml.gz
/var/cache/dnf/x86_64/22/rpmfusion-free/repodata/267567f56105d47142b79b6deced2acd108f81c5ef3185b87ff0e22ca9d4d790-filelists.xml.gz
/var/cache/dnf/x86_64/22/adobe-linux-x86_64/repodata/filelists.xml.gz
/var/cache/dnf/x86_64/22/rpmfusion-nonfree-updates/repodata/filelists.xml.gz
/var/cache/dnf/x86_64/22/updates/repodata/ecb2b5ea8fc2009a2848497a22b87270afe183330e2bc2fdbd91260690acf406-filelists.xml.gz
/var/cache/dnf/x86_64/22/brew/repodata/d2fb3f7be0173b3c016e66c642e94fec870b5b237dbd4583833166dca87967a0-filelists.xml.gz
/var/cache/dnf/x86_64/22/beaker-client/repodata/f8a45950aaed71759ac7dceafc93ef79918747704714182f0914bb0b5ab2d42e-filelists.xml.gz
/var/cache/dnf/x86_64/22/rpmfusion-nonfree/repodata/963e53309ee3e0c349e54a5cf2219dce233c5876d7bd9819152ef213616ded8c-filelists.xml.gz
/var/cache/dnf/x86_64/22/rhpkg/repodata/6668651d4395147b00320c88ea65824de6f6576371dddba0589da75c91fd8dd1-filelists.xml.gz

Since there seems to be discrepancy between what is believed and what is
the actual state, I queried DNF upstream what they think about it:

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

Vít

Dne 2.7.2015 v 21:52 Toshio Kuratomi napsal(a):
>
>
> On Jul 2, 2015 7:43 AM, "Vít Ondruch" <vondruch at redhat.com
> <mailto:vondruch at redhat.com>> wrote:
> >
> > Hi,
> >
> > I am trying to update rubygem-apipie-rails and on that occasion, I'm
> > going to unbundle the jquery. I did that by specifying "Requires:
> > js-jquery1" and replacing the original file by symlink. And now rpmlint
> > complains:
> >
> > rubygem-apipie-rails.noarch: W: dangling-symlink
> >
> /usr/share/gems/gems/apipie-rails-0.3.4/app/public/apipie/javascripts/bundled/jquery-1.7.2.js
> > /usr/share/javascript/jquery/1/jquery.js
> > The target of the symbolic link does not exist within this package or
> > its file
> > based dependencies.  Verify spelling of the link target and that the
> > target is
> > included in a package in this package's dependency chain.
> >
> >
> > I could resolve this by "Requires: %{_jsdir}/jquery/1/jquery.js" and I'd
> > love to do it, but this practice is discouraged by guidelines. Now I am
> > wondering:
> >
> > 1) Is this reasonable to use the file dependnecy in this case, although
> > it is outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin directories?
>
> Not if you can stop it another way which it appears you do.
>
> > 2) Does this reasoning: "Using file dependencies outside of those
> > directories requires yum (and other depsolvers using the repomd format)
> > to download and parse a large xml file looking for the dependency."
> > still holds with recent move to DNF?
>
> Not unless dnf always downloads the complete filelist repodata.  Since
> dnf is supposed to be faster than yum doubt that it does that.  Even
> if it did doo that it's likely that a future optimization would
> reestablish this behavior as the complete filelist is so big.
>
> > Isn't time to drop this paragraph?
>
> From the above description it hopefully is apparent that dropping out
> at this time would be detrimental. 
> > Isn't this "large xml" downloaded anyway for some reason?
>
> The large file being downloaded contains the complete mapping of
> packages to the files they contain.  This ain't of information is not
> needed in the majority of cases.  Usually the much smaller list of
> files (and package names and provides) which are contained in the main
> metadata is sufficient. The files which are in the main metadata are
> those which are in the directories listed in the guidelines.
>
> > Do we know
> > what is the real benefit, if there is some?
> >
>
> You can look at the sizes of the repo metadata files on a mirror (or
> in the yum cache if you were unfortunate enough to have to download
> the filelist for a previous transaction).  The savings is avoiding
> having to download the filelist.
>
> -Toshio
>
>
>
> --
> packaging mailing list
> packaging at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20150703/125915b8/attachment.html>