Bug 225725

---------
Summary:
---------
* License file in tarball but not in %doc
* Duplicate BuildRequires: autoconf (by automake), krb5-devel (by
openssl-devel), pkgconfig (by libidn-devel) 

---------
Details:
---------

OK - Mock : Built on rawhide (x86)
OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name.
OK - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
OK - License field in spec matches
OK - License is GPL
OK - License match packaging policy licenses allowed
FIX - License file is included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources SHOULD match upstream md5sum:
a0eb50e18a2ac8e77d6b0df8f94bb5a6  elinks-0.11.3.tar.bz2
OK - Package has correct buildroot.
FIX - BuildRequires are not redundant.
OK - %build and %install stages are correct and work.
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - No large doc files not in a -doc package
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories that other packages own.
OK - Changelog section is correct. 

OK - Should function as described.
OK - Should package latest version

---------------
Rpmlint output:
---------------
OK - silent on both srpm and main/sub package rpm

Silent on elinks and debuginfo

Source RPM:
W: elinks unversioned-explicit-provides webclient
W: elinks unversioned-explicit-obsoletes links
W: elinks unversioned-explicit-provides links

Package Change Request
======================
Package Name: elinks
Updated Fedora Owners: ovasik

I accidently did the review on F8 not devel.  The issues noted above are not in
devel branch.  

APPROVED

As far as I can tell, the unversionned obsoletes and provides are still there. They are gonna cause much trouble to bug 470703.

Please fix that, and fix it also in F8 and F9 and issue updates.

Another issue is that the symbolic link to links is dubious at best. It will also cause problem for bug 470703. What is your opinion on that? Why was it done in the first place?

Created attachment 323269 [details]
Fixes to the elinks.spec file to have it work with the 'links' package

Full spec file and srpm here:
http://matrix.senecac.on.ca/~jhford/fedora/elinks.spec
http://matrix.senecac.on.ca/~jhford/fedora/elinks-0.12-0.7.pre2.fc10.src.rpm

(In reply to comment #6)
> Created an attachment (id=323269) [details]
> Fixes to the elinks.spec file to have it work with the 'links' package
> 
> Full spec file and srpm here:
> http://matrix.senecac.on.ca/~jhford/fedora/elinks.spec
> http://matrix.senecac.on.ca/~jhford/fedora/elinks-0.12-0.7.pre2.fc10.src.rpm

It would have been better to keep the obsoletes, but version them by
using the links version number that was used when it was obsoleted.

The last upstream update to the old version of links 1 was made in 2003 and I looked as far back as I could in Fedora and it is exclusively elinks since at least Fedora core 5.  I could redo the patch with the versioned obsolete there, but I doubt that would have any real effect since as best as I can tell, there never has been an actual 'links' package in Fedora.

There was no links package in Fedora - last links package was 0.96 in RHEL2.1 and RHL7.3. Anyway, I'm not sure about dropping links symlinks as they are frequently used by elinks users for just running elinks. Versioned obsoletes are reasonable, I would suggest usage of different binary name in links package e.g. links2, links-g ... This is IMHO more safe solution... No patch for spec file is needed, we just have to discuss details what should be changed in elinks.

About the symlinks and their purpose at the beginning - I'm not sure, I guess it was because of keeping backward compatibility with some text-mode scripts as links package will probably bring requirements for X/framebuffer which could not be acceptable in some cases.
Versioned obsoletes will be fixed without doubts.

Tyler, Ondrej - ping?

I guess Tyler approved that package before, so no reason to ping him. Patrice afaik withdrawn from Fedora process ~1 month ago, I fixed versioned obsoletes in rawhide now, but I'm reluctant to remove links symlinks for links v2 package. Links v.2 (with graphics) brings framebuffer/X-Windows requirement. It is common in other linux distributions to have its binary named links2 and to ship links version 0.X or 1.X separately (RedHat shipped links v.0.X until 0.96, then replaced by elinks). I'm ok with removing those symlinks if the links v.1.X package will be added to Fedora - not for links v.2+. So the only question is if John is ok with it - then we could close that merge review again.

I withdrawn from Fedora, but I can still make evil comments ;-).

The versionned Obsoletes doesn't looks good to me. The Obsolete version
should be the old links version, not the elinks version.

So could be along

Obsoletes: links < 1:0.97
Provides: links <= 1:0.97-1

though I didn't found a full list of old links rpm in RHEL or fedora this seems to be fine, since as you said above 0.96 was the latest packages and upstream is already at 0.99 or 1.00pre.

Otherwise, I am fine with keeping the symlink as long as links is not brought back in fedora. Once it is in, maybe using alternatives would be better.

And I am also fine with using links2 for the links 2 package.

Ok, you are right, I thought about that possibility as well... will change the versioned obsoletes to that better style in next release... thanks for "evil comment" :).

Obsoletes should be fine now and links is now handled via alternatives. Maybe we should close that review again. What do you think?