[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [devel-ref] author/homepage in description

On 12/08/02 18:08, Adam DiCarlo wrote:

Ideally debian/control's known fields would be extended, e.g.,

  Upstream-Maintainer: John Doe <jdoe@foo.com>
  Upstream-Homepage: http://whatever.sourceforge.net/

Is this worthy of filing as a wishlist on dpkg?

Personally, there have been many times that I saw a new package announced in DWN and I would click the link to packages.debian.org, read the package description, and want more information. So I would then go to Google and try to find the homepage. I would like to see a URI on the packages page where I could click for more information, get screenshots, etc.

I really don't see much reason for an upstream maintainer, specifically, but a pointer to a mailing list or set of mailing lists (eg, there are several for GIMP) where I can search past archives or subscribe would be nice. For small projects, a single email may suffice, but this should be a URI for projects that may not have an email accessible gateway. I know of none offhand, but it just means to use a "mailto: Joe <j@foo>" instead of expecting an email address, which solves the 'set of mailing lists' problem, presuming there is a page listing them. Upsteam-Support: may be a better name, therefore.

I have also wanted to know from where the source was downloaded a few times - like which of the 8 versions of ghostscript did _this_ ghostscript package come from? if anything was taken out of CVS, and where did these patches come from? etc.

Most of this information can usually be found by reading pages upon pages upon pages of terse entries in /usr/share/doc/* but not always, and I can almost never find what I'm looking for anyway. bah! All that being said, Upstream-Support: and Upstream-Homepage: would be very helpful for the rubes like me, especially with automated tools that pull these out and put them on webpages. ;-)

  Author:   Norman Walsh <ndw@nwalsh.com>
  Homepage: http://docbook.sourceforge.net/

Some packages already do this, and it is appreciated. For something so formally structured I think it should migrate into the header.


Reply to: