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

Re: RFD: new optional field for 'control'

Dirk Eddelbuettel writes [un-superCited.  Die die die !  -iwj]:
> Bruce Perens writes:
> > [Ian Jackson wrote: ]
> > > If we were going to do this a separate admin info file (like
> > > `conffiles'), it would be more appropriate...
> > OK. I think the easiest way to deal with this is to distribute a
> > foo-2.5-0.html file with the package of the same name, and let the
> > script pick up that it is there.
> This leads to too much file clutter. Why not a debian.html or
> debian.control-html or whatever within the .deb package?

Yes, on reflection I think you're right about the file clutter (and
where would we put the .html file, anyway) ?  I suppose it's OK to put
things not destined directly at the end-user in the .deb files, so
long as they're kept small.

I suggest we use the name `html-desc'.  There's no point having
`debian' in it anywhere (the whole thing is a Debian archive), and
full stops are not allowed.  The name must be less than 14 characters,
because I intend to change the archive format at some point, to one
based on `ar'.

The file should be an fragment of an HTML body - ie, no <html> or
<body> tags.  As Bruce says, it should contain only absolute URL's.
The text itself should be practically identical to the standard
Description control file field.

Perhaps we need a scheme for making the names of other packages into
hyperlinks, when they appear in the description ?  <A package="...">
perhaps, and have it mangled by the formatter/processor.  References
to manpages might also be useful.

What about the first line of the description, which is usually a
summary ?  Perhaps we should just put it naked (ie, without tags) in
the html-desc file as the first line.

The file should not contain any HTML comments.  This is because they
are (a) hard to parse and (b) wasteful of space.

In order to get such a file into your package you can simply place it
in the DEBIAN directory like you do with the conffiles, postinst, &c.

The WWW site maintainer should:

Firstly, see if the file is present, with
 dpkg --info <file>.deb html-desc 2>/dev/null
If this returns a zero exit status it will have produced the
html-desc on stdout.

If this fails, use:
 dpkg --control <file>.deb description

The result should be formatted according to the rules for dselect
descriptions, which are available on the FTP site.  Basically, you
should turn all lines ` .' into <p> tags, and surround all sequences
of lines with more than one leading space with <pre> and </pre>.

Bruce Perens writes ("Re: RFD: new optional field for 'control' "):
> From: iwj10@cus.cam.ac.uk (Ian Jackson)
> > Remember, we're trying to concentrate on providing a good operating system,
> > not an impressive-looking WWW site.
> Here's where I have to differ: Marketing is very important. What good is
> Debian if nobody uses it? A good looking package list on the WWW site
> helps the prospective users decide if Debian has what they want, and thus
> helps the them decide to put Debian on their systems.

I think perhaps my original comment was too strong.  However, we
should be wary of the triumph of form over substance.

J. H. M. Dassen writes ("Re: RFD: new optional fields for 'control'"):
> In addition to "HTML-Description", an optional "Source" field would be 
> useful, for those binary packages whose source package name cannot be
> deduced from their name.
> I remember vaguely some discussion about a "Source" field. Ian J.? 

The `Source' field is now canon, I think.

On the 6th of July I wrote:
] I think the consensus on this issue is that it's a good idea.  I think
] we're pretty much agreed on:
] Package maintainers may optionally put Source fields in their package
] control files.  If they do so the field should contain the name
] (basename, that is) of the source package from which the binary was
] generated.
] Package maintainers with packages which build multiple .deb files from
] a single source will be encouraged, but not required, to do this.
] dpkg, dselect and so on will treat the Source package as opaque data
] and will simply display it to the user on request (usually as part of
] the other control information, using dpkg --status for example).

Noone objected, and since then I've uploaded a new set of Texinfo
packages with Source fields.


Reply to: