make URL tag mandatory

[Till Maas]

Hi,

I noticed that several packages do not contain a URL tag and
http://fedoraproject.org/wiki/Packaging:Guidelines#tags
does not require it. IMHO it would be nicer to have a valid URL tag for
all packages. Therefore I want to propose to make it mandatory.

What are your opinions?

Regards
Till

[Michael Schwendt]

On Mon, 12 Aug 2013 21:35:27 +0200, Till Maas wrote:

>  Hi,
>  
>  I noticed that several packages do not contain a URL tag and
>  http://fedoraproject.org/wiki/Packaging:Guidelines#tags
>  does not require it. IMHO it would be nicer to have a valid URL tag for
>  all packages. Therefore I want to propose to make it mandatory.
>  
>  What are your opinions? 
Both the package submitter and the reviewer, who approved the
package, should be pointed at:

  https://fedoraproject.org/wiki/Packaging:Guidelines#Use_rpmlint

  https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
  |
  | MUST: rpmlint must be run on the source rpm and all binary rpms
  | the build produces. The output should be posted in the review.

rpmlint warns about a missing URL tag.

[Till Maas]

On Mon, Aug 12, 2013 at 09:55:25PM +0200, Michael Schwendt wrote:
>  On Mon, 12 Aug 2013 21:35:27 +0200, Till Maas wrote: 
>  > I noticed that several packages do not contain a URL tag and
>  > http://fedoraproject.org/wiki/Packaging:Guidelines#tags
>  > does not require it. IMHO it would be nicer to have a valid URL tag for
>  > all packages. Therefore I want to propose to make it mandatory.
>  > 
>  > What are your opinions?
>  
>  Both the package submitter and the reviewer, who approved the
>  package, should be pointed at:
>  
>    https://fedoraproject.org/wiki/Packaging:Guidelines#Use_rpmlint
>  
>    https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
>    |
>    | MUST: rpmlint must be run on the source rpm and all binary rpms
>    | the build produces. The output should be posted in the review.
>  
>  rpmlint warns about a missing URL tag. 
I did not check why it happened. The packages from the following SRPM do
not seem to have the URL tag:

adjtimex-1.29-6.fc19.src.rpm
arptables_jf-0.0.8-32.fc19.src.rpm
autofs-5.0.7-14.fc19.src.rpm
basesystem-10.0-8.fc19.src.rpm
bitmap-fonts-0.3-20.fc19.src.rpm
bootparamd-0.17-38.fc19.src.rpm
checkpolicy-2.1.12-3.fc19.src.rpm
chkconfig-1.3.60-3.fc19.src.rpm
color-filesystem-1-12.fc19.src.rpm
crypto-utils-2.4.1-39.fc19.src.rpm
desktop-backgrounds-19.0.0-2.fc19.src.rpm
duel3-0.1-0.15.20060225.fc19.src.rpm
dwz-0.10-1.fc19.src.rpm
finger-0.17-48.fc19.src.rpm
floppy-support-1.0.0-5.fc19.src.rpm
fontmatrix-0.9.99-11.r1218.fc19.src.rpm
fonts-KOI8-R-1.0-17.fc19.src.rpm
freeze-2.5.0-15.fc19.src.rpm
generic-release-19-2.src.rpm
gnome-icon-theme-3.8.2-1.fc19.src.rpm
gnome-icon-theme-extras-3.6.2-2.fc19.src.rpm
gnome-icon-theme-symbolic-3.8.2.2-1.fc19.src.rpm
gnome-python2-desktop-2.32.0-14.fc19.src.rpm
google-croscore-fonts-1.23.0-2.fc19.src.rpm
greylistd-0.8.7-16.fc19.src.rpm
hesiod-3.2.1-1.fc19.src.rpm
icon-slicer-0.3-18.fc19.src.rpm
ilbc-1.1.1-4.fc19.src.rpm
imlib-1.9.15-23.fc19.src.rpm
iso8859-2-fonts-1.0-28.fc19.src.rpm
japanese-bitmap-fonts-0.20080710-13.fc19.src.rpm
jomolhari-fonts-0.003-16.fc19.src.rpm
joystick-support-1.0.0-5.fc19.src.rpm
kcc-2.3-34.src.rpm
kde-filesystem-4-45.fc19.src.rpm
kexec-tools-2.0.3-71.fc19.src.rpm
kinput2-v3.1-46.fc19.src.rpm
knm-new-fixed-fonts-1.1-18.fc19.src.rpm
konkretcmpi-0.9.0-5.fc19.src.rpm
libaio-0.3.109-7.fc19.src.rpm
libcroco-0.6.8-2.fc19.src.rpm
libdvdnav-4.2.0-4.fc19.src.rpm
libdvdread-4.2.0-4.fc19.src.rpm
librsvg2-2.37.0-3.fc19.src.rpm
mcstrans-0.3.3-6.fc19.src.rpm
mkbootdisk-1.5.5-10.fc19.src.rpm
mozilla-filesystem-1.9-9.fc19.src.rpm
mutter-3.8.3-1.fc19.src.rpm
netdump-server-0.7.16-32.fc19.src.rpm
newsx-1.6-18.fc19.src.rpm
perl-srpm-macros-1-7.fc19.src.rpm
preferences-menus-1-6.fc19.src.rpm
prelink-0.5.0-1.fc19.src.rpm
procinfo-18-32.fc19.src.rpm
pyorbit-2.24.0-13.fc19.src.rpm
rarpd-ss981107-40.fc19.src.rpm
rdma-2.0-8.fc19.src.rpm
rootfiles-8.1-10.fc19.src.rpm
rstp-04012009git-10.fc19.src.rpm
rwho-0.17-51.fc19.src.rpm
sirius-0.8.0-22.fc19.src.rpm
telepathy-filesystem-0.0.2-5.fc19.src.rpm
ttmkfdir-3.0.9-39.fc19.src.rpm
txt2rss-0.1-10.fc19.src.rpm
vnc-ltsp-config-4.0-11.fc19.src.rpm
vte3-0.34.6-1.fc19.src.rpm
xmms-speex-0.9.1-19.src.rpm
xorg-x11-drivers-7.7-5.fc19.src.rpm
scottfree-1.14-7.fc19.src.rpm
mutter-3.8.4-1.fc19.src.rpm
gnome-icon-theme-3.8.3-1.fc19.src.rpm
kexec-tools-2.0.4-7.fc19.src.rpm
konkretcmpi-0.9.1-1.fc19.src.rpm
fontmatrix-0.9.99-12.r1218.fc19.src.rpm
dwz-0.11-1.fc19.src.rpm
autofs-5.0.7-28.fc19.src.rpm

I used this script to generate the list:
#!/usr/bin/python -tt
import yum
if __name__ == "__main__":
    yb = yum.YumBase()
    all_packages = yb.pkgSack.returnPackages()
    bad_url = []
    for p in all_packages:
        if not p.url:
            if p.sourcerpm not in bad_url:
                print p.sourcerpm
                bad_url.append(p.sourcerpm)

Regards
Till

[Christopher Meng]

Nice script.

The  why these package's didn't follow the standard?

[Michael Schwendt]

On Tue, 13 Aug 2013 07:33:35 +0800, Christopher Meng wrote:

>  The  why these package's didn't follow the standard? 
Various reasons:

First of all, as mentioned, it's not an error. It's not rpmbuild that
would reject such a spec file. It's just rpmlint that warns about it. And
rpmlint has not been in use so much years ago (and possibly has not been
used much during the Merge Review era either).

Further, for some of the packages, there is no such URL. No home page.
Not even a download directory. Example:
http://pkgs.fedoraproject.org/cgit/basesystem.git/plain/basesystem.spec

Finally, sometimes (not limited to a missing-URL-tag) it's because the
packaging guidelines are not enforced by automated processes. And where
the guidelines say SHOULD instead of MUST, some people take that as
NEEDNOT -> LESSWORK -> DONE.

[Ankur Sinha]

On Mon, 2013-08-12 at 23:10 +0200, Till Maas wrote:
>  I did not check why it happened. The packages from the following
> SRPM
>  do
>  not seem to have the URL tag: 
Maybe this should be pointed out on the devel list with a request to all
maintainers to correct their spec files. If it isn't done in some time
frame, say a month, bugs should be filed against these packages. 
-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG

[Andrea Musuruane]

On Mon, Aug 12, 2013 at 11:10 PM, Till Maas <opensource(a)till.name&gt; wrote:

>  I did not check why it happened. The packages from the following SRPM
> do
>  not seem to have the URL tag:
>  [...]
>  scottfree-1.14-7.fc19.src.rpm
>  [...]
>  
I'm the maintainer of Scottfree (in RPM Fusion). It does not have an
upstream URL. File is distributed though the ftp site of the if-archive. So
I think it is perfectly sane not to have an URL tag.

Bye,

Andrea.

[Parag Nemade]

Hi Till,

On Tue, Aug 13, 2013 at 2:40 AM, Till Maas <opensource(a)till.name&gt; wrote:

>  On Mon, Aug 12, 2013 at 09:55:25PM +0200, Michael Schwendt wrote:
>  > On Mon, 12 Aug 2013 21:35:27 +0200, Till Maas wrote:
>
>  > > I noticed that several packages do not contain a URL tag and
>  > > http://fedoraproject.org/wiki/Packaging:Guidelines#tags
>  > > does not require it. IMHO it would be nicer to have a valid URL tag for
>  > > all packages. Therefore I want to propose to make it mandatory.
>  >
> >  
>  > > What are your opinions?
> >  
>  > Both the package submitter and the reviewer, who approved
> the
>  > package, should be pointed at:
> >  
>  >  
> https://fedoraproject.org/wiki/Packaging:Guidelines#Use_rpmlint
> >  
>  >  
> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
>  >   |
>  >   | MUST: rpmlint must be run on the source rpm and all binary rpms
>  >   | the build produces. The output should be posted in the review.
> >  
>  > rpmlint warns about a missing URL tag.
>
>  I did not check why it happened. The packages from the following SRPM do
>  not seem to have the URL tag:
>
>  adjtimex-1.29-6.fc19.src.rpm
>  arptables_jf-0.0.8-32.fc19.src.rpm
>  autofs-5.0.7-14.fc19.src.rpm
>  basesystem-10.0-8.fc19.src.rpm
>  
  why should this package need a source or URL?


>  bitmap-fonts-0.3-20.fc19.src.rpm
>  
We have seen issues with font upstream sources. When packages got added
into Fedora they of course used to have correct and valid upstream source
as well as URL. But as time goes these URL seems to vanish.

bootparamd-0.17-38.fc19.src.rpm
>  checkpolicy-2.1.12-3.fc19.src.rpm
>  
Looks like now source is also not able to be downloaded


>  chkconfig-1.3.60-3.fc19.src.rpm
>  
This looks like not requested any fedorahosted trac wiki, so there looks no
URL

color-filesystem-1-12.fc19.src.rpm
>  
This is a filesystem package so don't think any source or URL will exists
for it


> crypto-utils-2.4.1-39.fc19.src.rpm
> desktop-backgrounds-19.0.0-2.fc19.src.rpm
> duel3-0.1-0.15.20060225.fc19.src.rpm
> dwz-0.10-1.fc19.src.rpm
> finger-0.17-48.fc19.src.rpm
> floppy-support-1.0.0-5.fc19.src.rpm
> fontmatrix-0.9.99-11.r1218.fc19.src.rpm
>  
 Does your script checks for actual URL lines in SPEC that got commented?
The reason I have purposefully commented URL line is because upstream was
dead and I want to keep url for my reference as it was committed in initial
release. Do you got any recommendations for fixing this issue?

fonts-KOI8-R-1.0-17.fc19.src.rpm
>  
This is very old package in Fedora and whatever I can see about this
package, it never saw any URL and used sources from some website's download
space. That reminds me its merge review is still open as there is no trace
of source.


> freeze-2.5.0-15.fc19.src.rpm
>  
This is also old package with source hosted at http://www.ibiblio.org/pub/.
Can then this use URL as  http://www.ibiblio.org ??

generic-release-19-2.src.rpm
>  
This looks have its own upstream not hosted anywhere.

gnome-icon-theme-3.8.2-1.fc19.src.rpm
> gnome-icon-theme-extras-3.6.2-2.fc19.src.rpm
> gnome-icon-theme-symbolic-3.8.2.2-1.fc19.src.rpm
> gnome-python2-desktop-2.32.0-14.fc19.src.rpm
> google-croscore-fonts-1.23.0-2.fc19.src.rpm
>  
I have still not found any URL for this Google fonts project.


>  greylistd-0.8.7-16.fc19.src.rpm
>  hesiod-3.2.1-1.fc19.src.rpm
>  icon-slicer-0.3-18.fc19.src.rpm
>  ilbc-1.1.1-4.fc19.src.rpm
>  imlib-1.9.15-23.fc19.src.rpm 
iso8859-2-fonts-1.0-28.fc19.src.rpm
>  
Another old package. This was also not having any URL but source was hosted
on some website which is already dead now.

japanese-bitmap-fonts-0.20080710-13.fc19.src.rpm
>  
This uses various sources with some having URL link commented above source
lines in spec.

jomolhari-fonts-0.003-16.fc19.src.rpm
>  
Following is already in SPEC but if both URL is gone, can you suggest what
can be done to enable URL tag for this?

 # Looks like currently following URL is gone now. Maybe temporary issue
#URL:           http://chris.fynn.googlepages.com/jomolhari
# Try following URL for this package
#URL:
https://sites.google.com/site/chrisfynn2/home/fonts/jomolhari

joystick-support-1.0.0-5.fc19.src.rpm
> kcc-2.3-34.src.rpm
> kde-filesystem-4-45.fc19.src.rpm
>  
Another filesystem package


> kexec-tools-2.0.3-71.fc19.src.rpm
> kinput2-v3.1-46.fc19.src.rpm
> knm-new-fixed-fonts-1.1-18.fc19.src.rpm
>  
Its clearly written in spec
## the following upstream URL is a dead link anymore.
#URL:           http://www.din.or.jp/~storm/fonts/
#Source0:       http://www.din.or.jp/~storm/fonts/knm_new.tar.gz


> konkretcmpi-0.9.0-5.fc19.src.rpm
> libaio-0.3.109-7.fc19.src.rpm
> libcroco-0.6.8-2.fc19.src.rpm
> libdvdnav-4.2.0-4.fc19.src.rpm
> libdvdread-4.2.0-4.fc19.src.rpm
> librsvg2-2.37.0-3.fc19.src.rpm
> mcstrans-0.3.3-6.fc19.src.rpm
> mkbootdisk-1.5.5-10.fc19.src.rpm
> mozilla-filesystem-1.9-9.fc19.src.rpm
>  
This looks another filesystem package which should not be having any URL


> mutter-3.8.3-1.fc19.src.rpm
> netdump-server-0.7.16-32.fc19.src.rpm
> newsx-1.6-18.fc19.src.rpm
> perl-srpm-macros-1-7.fc19.src.rpm
> preferences-menus-1-6.fc19.src.rpm
>  
This is just single text file source with no upstream needed.


> prelink-0.5.0-1.fc19.src.rpm
> procinfo-18-32.fc19.src.rpm
>  
This is another package with source hosted on people page on some website.


> pyorbit-2.24.0-13.fc19.src.rpm
> rarpd-ss981107-40.fc19.src.rpm
> rdma-2.0-8.fc19.src.rpm
> rootfiles-8.1-10.fc19.src.rpm
> rstp-04012009git-10.fc19.src.rpm
> rwho-0.17-51.fc19.src.rpm
> sirius-0.8.0-22.fc19.src.rpm
> telepathy-filesystem-0.0.2-5.fc19.src.rpm
> ttmkfdir-3.0.9-39.fc19.src.rpm
>  
 The comment inside spec clearly mentioned its Red Hat maintained package
and source will be available from srpm. Let me see if I can add it to
fedorahosted and then its links in spec


> txt2rss-0.1-10.fc19.src.rpm
> vnc-ltsp-config-4.0-11.fc19.src.rpm
> vte3-0.34.6-1.fc19.src.rpm
> xmms-speex-0.9.1-19.src.rpm
> xorg-x11-drivers-7.7-5.fc19.src.rpm
> scottfree-1.14-7.fc19.src.rpm
> mutter-3.8.4-1.fc19.src.rpm
> gnome-icon-theme-3.8.3-1.fc19.src.rpm
> kexec-tools-2.0.4-7.fc19.src.rpm
> konkretcmpi-0.9.1-1.fc19.src.rpm
> fontmatrix-0.9.99-12.r1218.fc19.src.rpm
>  
 Duplicate in this list


> dwz-0.11-1.fc19.src.rpm
> autofs-5.0.7-28.fc19.src.rpm
>  
>  
We can uncomment the dead URL in
spec files but then what to do if someone
reports bug saying URL is not working? Close it as NOTABUG or WONTFIX?


Regards,
Parag.

[Till Maas]

On Tue, Aug 13, 2013 at 02:53:30PM +0530, Parag N(पराग़) wrote:

>  On Tue, Aug 13, 2013 at 2:40 AM, Till Maas
> <opensource(a)till.name&gt; wrote:
>  
>  > On Mon, Aug 12, 2013 at 09:55:25PM +0200, Michael Schwendt wrote:
>  > > On Mon, 12 Aug 2013 21:35:27 +0200, Till Maas wrote:
>  >
>  > > > I noticed that several packages do not contain a URL tag and
>  > > > http://fedoraproject.org/wiki/Packaging:Guidelines#tags
>  > > > does not require it. IMHO it would be nicer to have a valid URL tag for
>  > > > all packages. Therefore I want to propose to make it mandatory.
>  > > >
>  > > > What are your opinions?
>  > >
>  > > Both the package submitter and the reviewer, who approved the
>  > > package, should be pointed at:
>  > >
>  > >   https://fedoraproject.org/wiki/Packaging:Guidelines#Use_rpmlint
>  > >
>  > >   https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
>  > >   |
>  > >   | MUST: rpmlint must be run on the source rpm and all binary rpms
>  > >   | the build produces. The output should be posted in the review.
>  > >
>  > > rpmlint warns about a missing URL tag.
>  >
>  > I did not check why it happened. The packages from the following SRPM do
>  > not seem to have the URL tag:
>  >
>  > adjtimex-1.29-6.fc19.src.rpm
>  > arptables_jf-0.0.8-32.fc19.src.rpm
>  > autofs-5.0.7-14.fc19.src.rpm
>  > basesystem-10.0-8.fc19.src.rpm
>  >
>  
>    why should this package need a source or URL? 
A URL makes it obvious where the package comes from and does not hurt. I
would use https://fedoraproject.org/ here so everyone can see from "rpm
-qi basesystem" that it comes from Fedora.

>  > bitmap-fonts-0.3-20.fc19.src.rpm
>  >
>  
>  We have seen issues with font upstream sources. When packages got added
>  into Fedora they of course used to have correct and valid upstream source
>  as well as URL. But as time goes these URL seems to vanish.
>  
>  bootparamd-0.17-38.fc19.src.rpm
>  > checkpolicy-2.1.12-3.fc19.src.rpm
>  >
>  
>  Looks like now source is also not able to be downloaded
>  
>  
>  > chkconfig-1.3.60-3.fc19.src.rpm
>  >
>  
>  This looks like not requested any fedorahosted trac wiki, so there looks no
>  URL
>  
>  color-filesystem-1-12.fc19.src.rpm
>  > 
I would prefer to have at least a dead URL than no URL at all in the rpm
-qi output. This is at least one pointer in the right direction and is
less painful than to have to first checkout the SPEC to see where the
Source0 points to.

>  This is a filesystem package so don't think any source or URL
> will exists
>  for it 
IMHO for packages without upstream the URL should be
https://fedoraproject.org/

>  > fontmatrix-0.9.99-11.r1218.fc19.src.rpm
>  >
>  
>   Does your script checks for actual URL lines in SPEC that got commented?
>  The reason I have purposefully commented URL line is because upstream was
>  dead and I want to keep url for my reference as it was committed in initial
>  release. Do you got any recommendations for fixing this issue? 
I do not yet have recommendations, because I first wanted to find out
what the consensus is. I would prefer to for example check whether a
copy is available at archive.org and link there. If it is not, then
still the original URL is more helpful than having none at all, because
it only means that one needs to download the SPEC to find out, that the
URL does not work. Nevertheless a hint in the SPEC to indicate that it
is known that the URL does not work (preferable with a timestamp) is a
good idea and helps to later verification of valid URLs. My script just
checked the contents of the URL tag in binary RPMs.

>  fonts-KOI8-R-1.0-17.fc19.src.rpm
>  >
>  
>  This is very old package in Fedora and whatever I can see about this
>  package, it never saw any URL and used sources from some website's download
>  space. That reminds me its merge review is still open as there is no trace
>  of source.
>  
>  
>  > freeze-2.5.0-15.fc19.src.rpm
>  >
>  
>  This is also old package with source hosted at http://www.ibiblio.org/pub/.
>  Can then this use URL as  http://www.ibiblio.org ??
>  
>  generic-release-19-2.src.rpm
>  >
>  
>  This looks have its own upstream not hosted anywhere.
>  
>  gnome-icon-theme-3.8.2-1.fc19.src.rpm
>  > gnome-icon-theme-extras-3.6.2-2.fc19.src.rpm
>  > gnome-icon-theme-symbolic-3.8.2.2-1.fc19.src.rpm
>  > gnome-python2-desktop-2.32.0-14.fc19.src.rpm
>  > google-croscore-fonts-1.23.0-2.fc19.src.rpm
>  >
>  
>  I have still not found any URL for this Google fonts project. 
If there is no normal URL available, I would use the Sources URL.

I do not comment on the other examples, because they seem to be already
covered by the previous examples.

My suggestion would be:

- Packages must have a URL tag
- If possible, the URL should be valid
- If the package is completely created by Fedora, use
https://fedoraproject.org
- If there is no upstream web page, use the Source URL, or, if the web
  server allows directory listings, specify the directory of the Source
  URL
- If the original URL does not work, try an archive.org one and add a
  comment to the SPEC explaining when it was noticed that the URL does
  not work
- If archive.org does not work, use the last known URL and add a comment

An additional hack would be to add an achor tag to URLs that are known
to not work anymore, such as the following:

"http://example.com/#Fedora:+does+not+work,+no+new+URL+known"

>  We can uncomment the dead URL in spec files but then what to do if
> someone
>  reports bug saying URL is not working? Close it as NOTABUG or WONTFIX? 
WONTFIX or if it exists use CANTFIX. You can then link the bugzilla
entry in the SPEC.

However, these are only suggestions. But I find it annoying if "rpm -qi"
cannot explain where a package comes from.

Regards
Till

[Parag Nemade]

Hi,

On Wed, Aug 14, 2013 at 12:57 AM, Till Maas <opensource(a)till.name&gt; wrote:

>  If there is no normal URL available, I would use the Sources URL.
>
>  I do not comment on the other examples, because they seem to be already
>  covered by the previous examples.
>
>  My suggestion would be:
>
>  - Packages must have a URL tag
>  - If possible, the URL should be valid
>  - If the package is completely created by Fedora, use
>  https://fedoraproject.org
>  - If there is no upstream web page, use the Source URL, or, if the web
>    server allows directory listings, specify the directory of the Source
>    URL
>  - If the original URL does not work, try an archive.org one and add a
>    comment to the SPEC explaining when it was noticed that the URL does
>    not work
>  - If archive.org does not work, use the last known URL and add a comment
>
>  An additional hack would be to add an achor tag to URLs that are known
>  to not work anymore, such as the following:
>
>  "http://example.com/#Fedora:+does+not+work,+no+new+URL+known"
>
>  > We can uncomment the dead URL in spec files but then what to do if
>  someone
>  > reports bug saying URL is not working? Close it as NOTABUG or WONTFIX?
>
>  WONTFIX or if it exists use CANTFIX. You can then link the bugzilla
>  entry in the SPEC.
>
>  However, these are only suggestions. But I find it annoying if "rpm -qi"
>  cannot explain where a package comes from.
>
>  
  Thanks for your reply. I like these suggestions. I will use them in my
owned packages.

Regards,
Parag.

[Till Maas]

On Wed, Aug 14, 2013 at 08:31:30AM +0530, Parag N(पराग़) wrote:

>  On Wed, Aug 14, 2013 at 12:57 AM, Till Maas
> <opensource(a)till.name&gt; wrote: 
>    Thanks for your reply. I like these suggestions. I will use them in
> my
>  owned packages. 
I would wait a little, maybe it can be improved even more. For example
instead of using https://fedoraproject.org a wiki page explaining the
situation can be used.

Regards
Till

[Miroslav Suchý]

On 08/14/2013 07:43 AM, Till Maas wrote:
>  I would wait a little, maybe it can be improved even more. For
> example
>  instead of usinghttps://fedoraproject.org  a wiki page explaining the
>  situation can be used. 
+1

-- 
Miroslav Suchy,
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys

[Ralf Corsepius]

On 08/13/2013 09:27 PM, Till Maas wrote:

>  My suggestion would be:
>
>  - Packages must have a URL tag
>  - If possible, the URL should be valid
>  - If the package is completely created by Fedora, use
>  https://fedoraproject.org
>  - If there is no upstream web page, use the Source URL, or, if the web
>     server allows directory listings, specify the directory of the Source
>     URL
>  - If the original URL does not work, try an archive.org one and add a
>     comment to the SPEC explaining when it was noticed that the URL does
>     not work
>  - If archive.org does not work, use the last known URL and add a comment
>
>  An additional hack would be to add an achor tag to URLs that are known
>  to not work anymore, such as the following:
>
>  "http://example.com/#Fedora:+does+not+work,+no+new+URL+known" 
-1

I don't see how the effect would be different from not having an URL 
tag, except that your proposal causes more bureaucracy.

Ralf

[Till Maas]

On Wed, Aug 14, 2013 at 05:42:29AM +0200, Ralf Corsepius wrote:
>  On 08/13/2013 09:27 PM, Till Maas wrote:
>  
>  >My suggestion would be:
>  >
>  >- Packages must have a URL tag
>  >- If possible, the URL should be valid
>  >- If the package is completely created by Fedora, use
>  >https://fedoraproject.org
>  >- If there is no upstream web page, use the Source URL, or, if the web
>  >   server allows directory listings, specify the directory of the Source
>  >   URL
>  >- If the original URL does not work, try an archive.org one and add a
>  >   comment to the SPEC explaining when it was noticed that the URL does
>  >   not work
>  >- If archive.org does not work, use the last known URL and add a comment
>  >
>  >An additional hack would be to add an achor tag to URLs that are known
>  >to not work anymore, such as the following:
>  >
>  >"http://example.com/#Fedora:+does+not+work,+no+new+URL+known"
>  
>  -1
>  
>  I don't see how the effect would be different from not having an URL
>  tag, except that your proposal causes more bureaucracy. 
If I do "rpm -qi foo" on a package which this kind of URL it is directly
clear where the package came from and that it is not necessary to file a
bug about a bad URL. If the URL is missing, one would need to checkout
the SPEC and see which Sources are used and maybe file a bug report or
if the URL is there but broken, one might file an unnecessary bug
report. Therefore not having a URL tag leads to more work than just
adjusting the URL tag.

Regards
Till

[Ralf Corsepius]

On 08/14/2013 07:40 AM, Till Maas wrote:
>  On Wed, Aug 14, 2013 at 05:42:29AM +0200, Ralf Corsepius wrote:
> > On 08/13/2013 09:27 PM, Till Maas wrote:
> >
> >> My suggestion would be:
> >>
> >> - Packages must have a URL tag
> >> - If possible, the URL should be valid
> >> - If the package is completely created by Fedora, use
> >> https://fedoraproject.org
> >> - If there is no upstream web page, use the Source URL, or, if the web
> >>    server allows directory listings, specify the directory of the Source
> >>    URL
> >> - If the original URL does not work, try an archive.org one and add a
> >>    comment to the SPEC explaining when it was noticed that the URL does
> >>    not work
> >> - If archive.org does not work, use the last known URL and add a comment
> >>
> >> An additional hack would be to add an achor tag to URLs that are known
> >> to not work anymore, such as the following:
> >>
> >> "http://example.com/#Fedora:+does+not+work,+no+new+URL+known"
> >
> > -1
> >
> > I don't see how the effect would be different from not having an URL
> > tag, except that your proposal causes more bureaucracy.
>
>  If I do "rpm -qi foo" on a package which this kind of URL it is directly
>  clear where the package came from and that it is not necessary to file a
>  bug about a bad URL. If the URL is missing, one would need to checkout
>  the SPEC and see which Sources are used and maybe file a bug report or
>  if the URL is there but broken, one might file an unnecessary bug
>  report. Therefore not having a URL tag leads to more work than just
>  adjusting the URL tag. 
The effect of whether a package carries no URL:-tag or a 
"http:NoURL"-tag is equivalent.
=> Forcing packagers to use a "http:NoURL" to me qualifies as silly 
bureaucracy.

Whether a package should carry a URL: pointing to fedoraproject.org or 
net is a completely independent question.
Letting packages point to http://fedoraproject.org to me also is of very 
little practial use. If you want this to be of practical use, there 
should be a per-package URL, but ... this also means bureaucracy.

Ralf

[Till Maas]

On Wed, Aug 14, 2013 at 08:06:44AM +0200, Ralf Corsepius wrote:
>  On 08/14/2013 07:40 AM, Till Maas wrote:
>  >On Wed, Aug 14, 2013 at 05:42:29AM +0200, Ralf Corsepius wrote:
>  >>On 08/13/2013 09:27 PM, Till Maas wrote:
>  >>
>  >>>My suggestion would be:
>  >>>
>  >>>- Packages must have a URL tag
>  >>>- If possible, the URL should be valid
>  >>>- If the package is completely created by Fedora, use
>  >>>https://fedoraproject.org
>  >>>- If there is no upstream web page, use the Source URL, or, if the web
>  >>>   server allows directory listings, specify the directory of the Source
>  >>>   URL
>  >>>- If the original URL does not work, try an archive.org one and add a
>  >>>   comment to the SPEC explaining when it was noticed that the URL does
>  >>>   not work
>  >>>- If archive.org does not work, use the last known URL and add a comment
>  >>>
>  >>>An additional hack would be to add an achor tag to URLs that are known
>  >>>to not work anymore, such as the following:
>  >>>
>  >>>"http://example.com/#Fedora:+does+not+work,+no+new+URL+known"
>  >>
>  >>-1
>  >>
>  >>I don't see how the effect would be different from not having an URL
>  >>tag, except that your proposal causes more bureaucracy.
>  >
>  >If I do "rpm -qi foo" on a package which this kind of URL it is directly
>  >clear where the package came from and that it is not necessary to file a
>  >bug about a bad URL. If the URL is missing, one would need to checkout
>  >the SPEC and see which Sources are used and maybe file a bug report or
>  >if the URL is there but broken, one might file an unnecessary bug
>  >report. Therefore not having a URL tag leads to more work than just
>  >adjusting the URL tag.
>  
>  The effect of whether a package carries no URL:-tag or a
>  "http:NoURL"-tag is equivalent.
>  => Forcing packagers to use a "http:NoURL" to me qualifies as silly
>  bureaucracy. 
It is not the same. Say for example I want to find out what the upstream
for the locally installed package vte3 is. An easy way to do this would
be
rpm -qi vte3 | grep URL

but this does not give me any results. So what does this mean? Is the
upstream URL for vte3 dead? Is it an packager error? This cannot be
answered with the info from "rpm -qi". So now it becomes annoying and I
need to check out the sources.

$ dir=$(mktemp -d)
$ cd $dir
$ fedpkg clone -a vte3
$ cd vte3
$ grep Source vte3.spec
Source: http://download.gnome.org/sources/vte/0.34/vte-%{version}.tar.xz

Since gnome still exists and so does https://developer.gnome.org/vte/, I
see it is a packaging bug, but I still need to clean up:

$ cd 
$ rm -rf $dir

So there are at least six unnecessary steps required to find out whether
the missing URL tag is intentional or whether there is a packaging bug.
Therefore it is easier to just consider it always a packaging bug and
mark in the Tag if there is a URL known not to be working, because then
one might check whether the URL now works or at least knows that there
is no need to check for the sources and see if it is a packaging bug.

>  Whether a package should carry a URL: pointing to fedoraproject.org
>  or net is a completely independent question.
>  Letting packages point to http://fedoraproject.org to me also is of
>  very little practial use. If you want this to be of practical use,
>  there should be a per-package URL, but ... this also means
>  bureaucracy. 
Pointing to Fedora makes it explicit that it is a package created by
Fedora and that all sources are only to be found in the packaging GIT.
However, also a wiki page explaining this can be used, but what
different content would you put in the per-package URL? If there is
something to write for each package, then it should be there of course.
But for my intentions to find out where a package comes from with "rpm
-qi", it is enough to know that it is created by Fedora and that the
packaging GIT is the source for it.

Regards
Till

[Christopher Meng]

Fedora doesn't provide homepage service like Debian or GNU, there is no
reason we should write the URL with fp.o. Users will ask why you write the
homepage fp.o but acgually nothing is here?

I don't know if NO-URL will affect usability and aesthetics of
apps.fp.o/packages, but I think if some packages don't have URL, we should
leave it blank with some words.