Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Christian Perrier]

Quoting Manoj Srivastava ([EMAIL PROTECTED]):

> Right. These are staid, old, boring, unchanging fields; and
>  maintainers need not expect these to change; and putting them in policy
>  means that even dpkg can't change the fields drastically  fro under the
>  developers.
> 
> However, policy is not exhaustive; and if policy says nothing on
>  a topic, it means the topic is permitted, not prohibited; so the
>  Homepage: field can be used by any package without the package falling
>  foul of policy.

OK. I am not very strongly pushing the idea of documenting first in
the policy. This was just about exploring the various possibilities.

I keep you comment about the proposed changes to the policy being
roughly OK. I added them to the wiki page but kept those policy
changes coming after other changes such as APT frontends
implementation, devref update, dh-make and lintian/linda stuff.


> So, while I will not prevent you from going the route you
>  proposed, if you feel it is the right thing to do, I would still advice
>  caution. Having said that, I am not sure what changes might be needed
>  for home page fields (is there a concept like ultiple homepages?), but


It seems that very few packages currently use multiple URLs in the
pseudo-field in the package's description. 

So we could maybe allow that field to be multi-valued...




signature.asc
Description: Digital signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Manoj Srivastava]

On Sat, 22 Sep 2007 08:56:29 +0200, Christian Perrier <[EMAIL PROTECTED]> said: 

> Quoting Manoj Srivastava ([EMAIL PROTECTED]):
>> Actually, policy is usually the last thing that you want to do, in
>> the general case.  Policy is usually stable (well, not quite as
>> stable as it has been this year, but work seems to be easing up a
>> trifle, so expect a policy release in a couple of weeks).
>> 
>> But the idea is that policy documents mature practice, and only when
>> it is deemed really required.  Since so few packages do the Homepage
>> thing, I would much rather see a working design, supported by apt and
>> p.d.o, make any changes or tweaks as are needed; and _then_ we look
>> at policy.  If very few packages are using it still, you'll have to
>> start with a MAY or suggests, anyway.

> That was my initial idea: have the policy document after the practice
> became common practice as I remember that you (Manoj, but also often
> aj) often remind that the Policy is more about documenting common
> practice and turning it into 'rules' thanestablishing rules before
> they're really used.

> However, re-reading the part that describes debian/control fields in
> the policy, I noticed that they're describe in the *policy* and not in
> the DevRef.

Right. These are staid, old, boring, unchanging fields; and
 maintainers need not expect these to change; and putting them in policy
 means that even dpkg can't change the fields drastically  fro under the
 developers.

However, policy is not exhaustive; and if policy says nothing on
 a topic, it means the topic is permitted, not prohibited; so the
 Homepage: field can be used by any package without the package falling
 foul of policy.

> So, my thought when I proposed to begin with the policy was to have it
> describe that field without making it mandatory (MAY requirement, not
> MUST requirement) so that lintian/linda can point developers to it
> when issuing a warning for the missing field.

> So I roughly propose to:

> - Add an item to "5.3 Binary package control files -- DEBIAN/control":
>   - Homepage
>   (note the missing "mandatory")

> - Add a level 3 section to 5.6 List of fields: 5.6.x Homepage
> The upstream project home page URL. It should preferably contain and
> http(s) URL linking to a page describing the upstream project with
> access to the project's resources. This is an optional field

This looks like a sound addition to policy.  Have you given any
 thought to a lintian/linda check? (make sure it is a legal URI,
 optionally check to see if it is a valid URL pointing to a real web
 page, etc). Yes, I am still trying to thing about machine readable
 policy documents :)

> Would this better field for an early integration in the policy or do
> you still recommend that it comes after implementation in aptish tools
> and adoption by "enough" packages (probably following integration in
> lintian/linda)?

Well. When it comes to policy, I am very conservative (I am
 still smarting from the /usr/doc transition fiasco).  Remember the
 X-SVN: field? After we thought it was all decided, arch came up, and we
 split the single field into a browser and a repo field; and that came
 only after it was implemented, people started using it, and other folks
 (arch users, like me) came up with suggestions an changes, and the
 fields were changed.

It would have been much harder to do so if we had to wait for
 policy to change. (I know, I know. Slow policy changes are at least
 partially my fault).

So, while I will not prevent you from going the route you
 proposed, if you feel it is the right thing to do, I would still advice
 caution. Having said that, I am not sure what changes might be needed
 for home page fields (is there a concept like ultiple homepages?), but
 I have often found that people have far more imagination than I have.

manoj
-- 
"It's what you learn after you know it all that counts." John Wooden
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Christian Perrier]

Quoting Manoj Srivastava ([EMAIL PROTECTED]):
> Actually, policy is usually the last thing that you want to
>  do, in the general case.  Policy is usually stable (well, not quite as
>  stable as it has been this year, but work seems to be easing up a
>  trifle, so expect a policy release in a couple of weeks).
> 
> But the idea is that policy documents mature practice, and only
>  when it is deemed really required.  Since so few packages do the
>  Homepage thing, I would much rather see a working design, supported by
>  apt and p.d.o, make any changes or tweaks as are needed; and _then_ we
>  look at policy.  If very few packages are using it still, you'll have
>  to start with a MAY or suggests, anyway.


That was my initial idea: have the policy document after the practice
became common practice as I remember that you (Manoj, but also often
aj) often remind that the Policy is more about documenting common
practice and turning it into 'rules' thanestablishing rules before
they're really used.

However, re-reading the part that describes debian/control fields in
the policy, I noticed that they're describe in the *policy* and not in
the DevRef.

So, my thought when I proposed to begin with the policy was to have it
describe that field without making it mandatory (MAY requirement, not
MUST requirement) so that lintian/linda can point developers to it
when issuing a warning for the missing field.

So I roughly propose to:

- Add an item to "5.3 Binary package control files -- DEBIAN/control":
  - Homepage
  (note the missing "mandatory")

- Add a level 3 section to  5.6 List of fields:
  5.6.x Homepage
The upstream project home page URL. It should preferably
contain and http(s) URL linking to a page describing the upstream
project with access to the project's resources. This is an optional
field


Would this better field for an early integration in the policy or do
you still recommend that it comes after implementation in aptish tools
and adoption by "enough" packages (probably following integration in 
lintian/linda)?





signature.asc
Description: Digital signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Adeodato Simó]

* Manoj Srivastava [Fri, 21 Sep 2007 16:51:03 -0500]:

> On Fri, 21 Sep 2007 22:08:12 +0300, Lars Wirzenius <[EMAIL PROTECTED]> said: 
> > At the very least, lintian should stop warning about Homepage:, right?
> > (Sorry if it already doesn't warn, I haven't had time to upgrade and
> > the machine hosting my mirror decided to commit suicide today.)

> Err, I did not find it warned me about my fvwm uploads, so that
>  part is done too.

Try `lintian -I`. (Because the warning was not a W:arning, but an I:nfo
item.)

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Don't be irreplaceable, if you can't be replaced, you can't be promoted.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Manoj Srivastava]

On Fri, 21 Sep 2007 22:08:12 +0300, Lars Wirzenius <[EMAIL PROTECTED]> said: 

> pe, 2007-09-21 kello 16:44 +0200, Adeodato Simó kirjoitti:
>> * Christian Perrier [Thu, 20 Sep 2007 18:02:56 +0200]:
>> 
>> > Again, please comment,
>> 
>> Personally, I think the change that should really go first is
>> lintian/linda (emitting a warning for packages that put the homepage
>> in the description),

> At the very least, lintian should stop warning about Homepage:, right?
> (Sorry if it already doesn't warn, I haven't had time to upgrade and
> the machine hosting my mirror decided to commit suicide today.)

Err, I did not find it warned me about my fvwm uploads, so that
 part is done too.

manoj
-- 
Some marriages are made in heaven -- but so are thunder and lightning.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Lars Wirzenius]

pe, 2007-09-21 kello 16:44 +0200, Adeodato Simó kirjoitti:
> * Christian Perrier [Thu, 20 Sep 2007 18:02:56 +0200]:
> 
> > Again, please comment,
> 
> Personally, I think the change that should really go first is lintian/linda
> (emitting a warning for packages that put the homepage in the description),

At the very least, lintian should stop warning about Homepage:, right?
(Sorry if it already doesn't warn, I haven't had time to upgrade and the
machine hosting my mirror decided to commit suicide today.)

-- 
Code is cheap to write.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Adeodato Simó]

* Christian Perrier [Thu, 20 Sep 2007 18:02:56 +0200]:

> Again, please comment,

Personally, I think the change that should really go first is lintian/linda
(emitting a warning for packages that put the homepage in the description),
since that's what will make most packages change, and will give the
Homepage field the status quo needed to make it into devref and policy.

It will also make the size of the mass bug filings smaller, though I'm
not sure I like the idea of a MBF for this.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The true teacher defends his pupils against his own personal influence.
-- Amos Bronson Alcott


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Raphael Hertzog]

On Fri, 21 Sep 2007, Manoj Srivastava wrote:
>  Homepage thing, I would much rather see a working design, supported by
>  apt and p.d.o, make any changes or tweaks as are needed; and _then_ we

p.d.o already supports it. "apt-cache show" obviouly displays the field.

The work left concerns higher-level user interface like aptitude and
synaptic. Someone should file bugs against them for a start (I checked and
none of them have a bug with a subject matching /homepage/).

Maybe update-manager too.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Manoj Srivastava]

On Thu, 20 Sep 2007 18:02:56 +0200, Christian Perrier <[EMAIL PROTECTED]> said: 

> Quoting Lars Wirzenius ([EMAIL PROTECTED]):
>> I'd start with amending the Developers' Reference, then having a test
>> added to lintian and linda, and after that announcing it on
>> debian-devel-announce. Then next year, after everyone's had time to
>> react and upload new packages, do a mass bug filing.

> I'd probably add a changes to section 5.6 of the Policy (List of
> fields) before adding a test to lintian and linda.

> Then file a bug against *apt* packages and p.d.o to have them support
> displaying info from that field, before or after the d-d-a
> announcement.

> I'm not sure whether to amend the DevRef first as it usually documents
> "best practices"which will probably become best practices once
> enough people started using them.

> So, maybe documenting the field in the Policy, first, would be the
> best to do.

> Then DevRef, then lintian/linda, the d-d-a announcement.

Actually, policy is usually the last thing that you want to
 do, in the general case.  Policy is usually stable (well, not quite as
 stable as it has been this year, but work seems to be easing up a
 trifle, so expect a policy release in a couple of weeks).

But the idea is that policy documents mature practice, and only
 when it is deemed really required.  Since so few packages do the
 Homepage thing, I would much rather see a working design, supported by
 apt and p.d.o, make any changes or tweaks as are needed; and _then_ we
 look at policy.  If very few packages are using it still, you'll have
 to start with a MAY or suggests, anyway.

Oh, if anyone has any ideas about the docbook template for
 policy rules, now is the time to send them in.  I am planning on
 spending time on all the policy related proposals I talked about at
 debconf.

manoj
-- 
Murder is contrary to the laws of man and God. M-5 Computer, "The
Ultimate Computer", stardate 4731.3
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Patrick Schoenfeld]

Hi,

IANADD but...

Christian Perrier wrote:
> Then file a bug against *apt* packages and p.d.o to have them support
> displaying info from that field, before or after the d-d-a
> announcement.

you wrote what I thought when I read this proposal. After all it makes
sense to first add support for the field in every important app (that
includes p.d.o and apt off course) before there are bugs filed against
packages.

> So, maybe documenting the field in the Policy, first, would be the
> best to do.
> 
> Then DevRef, then lintian/linda, the d-d-a announcement.

Hm. If you say that this should be specified in DevRef  when enough
people are using it, but you prefer to documenting the field in the
Policy first, then I think this order is wrong. Probably should
lintian/linda be changed all together with the policy and then announced.

> Then, a while later, it could become time to think about making this
> field mandatory or not and send another MBF against packages that
> don't have it at all.

Wouldn't it make sense to make it mandatory from the beginning of a
policy change?

Just my 2 cents.

Best Regards,

Patrick


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Christian Perrier]

Quoting Lars Wirzenius ([EMAIL PROTECTED]):

> I'd start with amending the Developers' Reference, then having a test
> added to lintian and linda, and after that announcing it on
> debian-devel-announce. Then next year, after everyone's had time to
> react and upload new packages, do a mass bug filing.


I'd probably add a changes to section 5.6 of the Policy (List of
fields) before adding a test to lintian and linda.

Then file a bug against *apt* packages and p.d.o to have them support
displaying info from that field, before or after the d-d-a
announcement.

I'm not sure whether to amend the DevRef first as it usually documents
"best practices"which will probably become best practices once
enough people started using them.

So, maybe documenting the field in the Policy, first, would be the
best to do.

Then DevRef, then lintian/linda, the d-d-a announcement.

After enough time, we could first send a MBF on packages that match 
"^ +[Hh]ome[Pp]age:" in their description to suggest moving this to
the new field.

Then, a while later, it could become time to think about making this
field mandatory or not and send another MBF against packages that
don't have it at all.


Again, please comment, particularly about the order of changes in
developers documentation. I think this summarizes what I've read as
of now.






signature.asc
Description: Digital signature

Wiki page (was Re: [RFC] Promoting the use of "Homepage:" field in debian/control)

[Philippe Cloutier]

>
> I'd start with amending the Developers' Reference, then having a test
> added to lintian and linda, and after that announcing it on
> debian-devel-announce. Then next year, after everyone's had time to
> react and upload new packages, do a mass bug filing.
Basically agreed. I created 
http://wiki.debian.org/HomepageFieldTransition adding a few things.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Wiki page (was Re: [RFC] Promoting the use of "Homepage:" field in debian/control)

[Philippe Cloutier]

I'd start with amending the Developers' Reference, then having a test
added to lintian and linda, and after that announcing it on
debian-devel-announce. Then next year, after everyone's had time to
react and upload new packages, do a mass bug filing.
Basically agreed. I created 
http://wiki.debian.org/HomepageFieldTransition adding a few things.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Joey Hess]

Luca Capello wrote:
> This is strange: the Homepage field is shown for some packages [1] and
> not for others [2], e.g. reported below:
> =
> [EMAIL PROTECTED]:~$ apt-cache show ikiwiki | grep "^Homepage"
> Homepage: http://ikiwiki.info/
> 
> [EMAIL PROTECTED]:~$ apt-cache show deb-gview | grep "^Homepage"
> Homepage: http://dpkg-view.alioth.debian.org/

IIRC this is because the alpha buildd didn't have a new version of dpkg
on it, so didn't generate debs with the Homepage field, and packages.d.o
looks at alpha packages first when generating pages for binaries. (So
the source pages should be ok.) There was a thread about this recently.
I don't know if the alpha buildd has been updated yet.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Luca Capello]

Hello!

On Thu, 20 Sep 2007 10:31:31 +0200, Michal Čihař wrote:
> On Thu, 20 Sep 2007 07:05:04 +0200 Christian Perrier <[EMAIL PROTECTED]> 
> wrote:
>> As a consequence, it seems logical to promote the use of that field
>> and recommend abandoning "Homepage" paragraphs in packages'
>> description.
>
> Well I started to use this field in some my packages, but I see few
> problems:
>
> 1. Policy does not cover this field, you will also get "I:
> unknown-field-in-control homepage" from lintian.

This is a minor warning.

> 2. packages.debian.org/aptitude/other tools does not support this
> field.  This means that moving Homepage from description to separate
> field for now means that no user will be able to see it.

This is strange: the Homepage field is shown for some packages [1] and
not for others [2], e.g. reported below:
=
[EMAIL PROTECTED]:~$ apt-cache show ikiwiki | grep "^Homepage"
Homepage: http://ikiwiki.info/

[EMAIL PROTECTED]:~$ apt-cache show deb-gview | grep "^Homepage"
Homepage: http://dpkg-view.alioth.debian.org/

[EMAIL PROTECTED]:~$ 
=

FWIW, the number of source packages implementing the Homepage: field
is still very very low:
=
[EMAIL PROTECTED]:~$ wget 
http://ftp.ch.debian.org/debian/dists/sid/main/source/Sources.gz
[EMAIL PROTECTED]:~$ zgrep -c "^Package" Sources.gz
11659
[EMAIL PROTECTED]:~$ zgrep -c "^Homepage" Sources.gz
20
[EMAIL PROTECTED]:~$
=

/me goes to move the homepage from Description: to Homepage: for his
packages...

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://packages.debian.org/sid/ikiwiki
[2] http://packages.debian.org/sid/deb-gview


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Stefano Zacchiroli]

On Thu, Sep 20, 2007 at 11:22:14AM +0200, Andreas Tille wrote:
> Moreover I said that we might be able to parse debian/copyright for
> potential homepage strings.

Yep, I got that, sorry for not replying on it.

But this does not seem really feasible to me: in debian/copyright you
almost always have some URL (at least in packages generated in the last
5(?) years with dh_make), but it's hard to tell if it's a homepage
rather than an apache directory listing or some version control system
or something like that ..

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Andreas Tille]

On Thu, 20 Sep 2007, Stefano Zacchiroli wrote:


Ah, ok, so probably the initial proposal was to file bugs against
packages using the pseudo Homepage field in the description, asking the
maintainers to convert it in the new one.


No I think you did understand the initial proposal right, but I was
suggesting how we might more or less prevent false positives (while
missing all those that have no homepage mentioned at all).  My idea
also extends to those that do not use the string "homepage" or
"URL" in their control file but also list *any* URL in free text
in their description which is not inconvient and might have good
chances to be a link to the real home page.


That's of course trivial (and
still welcome). I was thinking about how to bug packages to actually
include an Homepage field where is actually missing ...


Moreover I said that we might be able to parse debian/copyright for
potential homepage strings.

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Stefano Zacchiroli]

On Thu, Sep 20, 2007 at 10:49:17AM +0200, Andreas Tille wrote:
> Bugging those packages that contain an url in the description first?
> Perhaps grepping debian/copyright for potential homepage strings?

Ah, ok, so probably the initial proposal was to file bugs against
packages using the pseudo Homepage field in the description, asking the
maintainers to convert it in the new one. That's of course trivial (and
still welcome). I was thinking about how to bug packages to actually
include an Homepage field where is actually missing ...

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Andreas Tille]

On Thu, 20 Sep 2007, Stefano Zacchiroli wrote:


To me it doesn't seem easy to implement. The naive solution of bugging
all package without a Homepage field will not work because not all
package probably have an Homepage; I agree that the false negatives
would be only a few, but that's not a valid reason for bugging
non-bugged packages.

Other ideas?


Bugging those packages that contain an url in the description first?
Perhaps grepping debian/copyright for potential homepage strings?

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Stefano Zacchiroli]

On Thu, Sep 20, 2007 at 09:57:44AM +0200, Christoph Haas wrote:
> > Of course, a mass bug-filing could also later happen but that would
> > probably be a *huge* bug filing which should be avoided now. Entering
> > a transition period where all communication media towards develpers
> > are used to suggest switching to the use of this field would be more
> > appropriate.
> Unless there are any reasons not to use the field someone (tm) should
> announce it on debian-devel-announce. Perhaps some time later a mass bug
> filing could be done with a "minor" priority.

Agreed, I would welcome the mass bug filing and I would love to see my
packages bugged so that to have a roadmap of which need to be fixed.

Still, out of curiosity, how do you guys plan to do the mass bug filing?
To me it doesn't seem easy to implement. The naive solution of bugging
all package without a Homepage field will not work because not all
package probably have an Homepage; I agree that the false negatives
would be only a few, but that's not a valid reason for bugging
non-bugged packages.

Other ideas?

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Michal Čihař]

Hi

On Thu, 20 Sep 2007 07:05:04 +0200
Christian Perrier <[EMAIL PROTECTED]> wrote:

> As a consequence, it seems logical to promote the use of that field
> and recommend abandoning "Homepage" paragraphs in packages'
> description.
> 
> As, in the Smith review project conducted on debian-l10n-english, we
> review packages' descriptions, we would like to get more input about
> recommending the use of that new field from now.
> 
> Are there any reasons *not* to do so (such as other tools that would be
> broken or the like)?

Well I started to use this field in some my packages, but I see few
problems:

1. Policy does not cover this field, you will also get "I:
unknown-field-in-control homepage" from lintian.

2. packages.debian.org/aptitude/other tools does not support this field.
This means that moving Homepage from description to separate field for
now means that no user will be able to see it.

These are definitely not a showstoppers, but I think that they should
be resolved first before pushing Homepage field to be used.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Lars Wirzenius]

to, 2007-09-20 kello 07:05 +0200, Christian Perrier kirjoitti:
> Of course, a mass bug-filing could also later happen but that would
> probably be a *huge* bug filing which should be avoided now. Entering
> a transition period where all communication media towards develpers
> are used to suggest switching to the use of this field would be more
> appropriate.
> 
> Of course, documents such as the Developer's Reference wuold then need
> to be adapted.

I'd start with amending the Developers' Reference, then having a test
added to lintian and linda, and after that announcing it on
debian-devel-announce. Then next year, after everyone's had time to
react and upload new packages, do a mass bug filing.

-- 
It's 1978! Things should be round by now -- Michael Kelso (That 70's
show)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Promoting the use of "Homepage:" field in debian/control

[Christoph Haas]

On Thu, Sep 20, 2007 at 07:05:04AM +0200, Christian Perrier wrote:
> A recent discussion back in August, in -devel, showed that the current
> common trick of using a "Homepage:" pseudo-field in binary packages'
> descriptions is not really optimal.

Indeed. It's formally specified to be used in the description field. So
IMO it definitely belongs into the group control fields instead.
In the worst case I have to get the package and read debian/copyright to
find out where about the upstream's home page.

> In the discussion, it was pointed that dpkg, as of 1.14.6, supports
> the use of a "Homepage:" field in debian/control.
> 
> As a consequence, it seems logical to promote the use of that field
> and recommend abandoning "Homepage" paragraphs in packages'
> description.
> 
> As, in the Smith review project conducted on debian-l10n-english, we
> review packages' descriptions, we would like to get more input about
> recommending the use of that new field from now.
> 
> Are there any reasons *not* to do so (such as other tools that would be
> broken or the like)?

I couldn't think of any.

> Of course, a mass bug-filing could also later happen but that would
> probably be a *huge* bug filing which should be avoided now. Entering
> a transition period where all communication media towards develpers
> are used to suggest switching to the use of this field would be more
> appropriate.

Unless there are any reasons not to use the field someone (tm) should
announce it on debian-devel-announce. Perhaps some time later a mass bug
filing could be done with a "minor" priority.

Having the field easily parseable would definitely make my life easier.
E.g. sponsors could be pointed to the upstream's home page from
mentors.debian.net so they quickly see in advance what application they
are considering to sponsor.

Cheers
 Christoph
-- 
Peer review means that you can feel better because someone else
missed the problem, too.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]