Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 225725 - Merge Review: elinks
Summary: Merge Review: elinks
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tyler Owen
QA Contact: Fedora Package Reviews List
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-31 18:32 UTC by Nobody's working on this, feel free to take it
Modified: 2009-07-20 13:25 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-20 13:25:28 UTC
tyler.l.owen: fedora-review+
wtogami: fedora-cvs+

Attachments (Terms of Use)
Fixes to the elinks.spec file to have it work with the 'links' package (deleted)
2008-11-11 22:41 UTC, John F
no flags Details | Diff

Description Nobody's working on this, feel free to take it 2007-01-31 18:32:44 UTC
Fedora Merge Review: elinks
Initial Owner:

Comment 1 Tyler Owen 2007-07-21 15:03:17 UTC
* License file in tarball but not in %doc
* Duplicate BuildRequires: autoconf (by automake), krb5-devel (by
openssl-devel), pkgconfig (by libidn-devel) 


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

Comment 2 Ondrej Vasik 2007-07-27 08:49:00 UTC
Package Change Request
Package Name: elinks
Updated Fedora Owners:

Comment 3 Tyler Owen 2008-01-15 14:21:14 UTC
I accidently did the review on F8 not devel.  The issues noted above are not in
devel branch.  


Comment 4 Patrice Dumas 2008-11-11 14:17:22 UTC
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.

Comment 5 Patrice Dumas 2008-11-11 14:23:21 UTC
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?

Comment 6 John F 2008-11-11 22:41:20 UTC
Created attachment 323269 [details]
Fixes to the elinks.spec file to have it work with the 'links' package

Full spec file and srpm here:

Comment 7 Patrice Dumas 2008-11-12 00:01:51 UTC
(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:

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.

Comment 8 John F 2008-11-12 05:35:35 UTC
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.

Comment 9 Ondrej Vasik 2008-11-13 08:15:43 UTC
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.

Comment 10 Ondrej Vasik 2008-11-13 08:28:49 UTC
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.

Comment 11 Robert Scheck 2009-01-13 22:25:34 UTC
Tyler, Ondrej - ping?

Comment 12 Ondrej Vasik 2009-01-14 11:22:27 UTC
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.

Comment 13 Patrice Dumas 2009-01-14 13:55:35 UTC
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.

Comment 14 Ondrej Vasik 2009-01-14 15:06:53 UTC
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" :).

Comment 15 Ondrej Vasik 2009-07-18 18:18:34 UTC
Obsoletes should be fine now and links is now handled via alternatives. Maybe we should close that review again. What do you think?

Note You need to log in before you can comment on or make changes to this bug.