Re: Consistent formating long descriptions as input data
On Thu, Apr 23 2009, Andreas Tille wrote:
> On Thu, 23 Apr 2009, Manoj Srivastava wrote:
>
>> While I can't speak for the policy team (I have not been
>> re-delegated yet), I suspect the answer might be to get a working
>> implementation out in the wild (it does not have to be packages.d.o or
>> anything official -- even a standalone software that takes the output
>> from grep-dctrl or parses a Packages file will suffice). This will
>> allow us to see what changes to policy might be needed, if any, for
>> package descriptions.
>
> Would you consider the tasks pages I announced yesterday [1] as such
> an implementation.
Sure. It would be great to have another implementation, perhaps
one that people can play with (something that, for example, one can
pipe the output of a grep-dctrl command to, and get an html snippet
from (hey, that can then be packaged as an ikiwiki plugin).
But the task pages should count as an implementation.
>
> I tried to detect some examples which need some changes. You might
> like to have a look at my "Debugging Blend":
>
> http://blends.debian.net/debug/tasks
>
> Some issues are mentioned there - I intend to add some better
> documentation if needed but some issues become clear.
Thanks. Once you are through, perhaps some directives for long
description policy can be derived from that.
> 1. The preprocessing you have to do for markdown is basically
> the same I did for turning description text into html
> programmatically myself. There is no real benefit if your
> main target is only HTML - however, other output formats
> might benefit from using the preprocessing + markup step.
> 2. Markdown is probably better in detecting second level lists
> thank I would have done it programmatically - so here is
> a benefit. On the other hand there are some strange false
> positives for second level lists.
These should be something we can look at to provide a policy
recommendation so these false positives can be reduced.
> 3. If we really are doing preprocessing it would be cheap to
> use 's/\so\s/ * /' and even this marker might be detected
> as list marker. This would be perfectly in contrast to my
> initial suggestion - but consequent if you prefer
> preprocessing anyway. BTW, I even detected non-ASCII
> bullets in the burn package and because it is QA maintained
> anyway I took the chance to change this while fixing bug
> #517793. I think we should catch things like this quite
> quickly because even apt-cache show failed to disply
> the description of burn correctly and so I've though
> fixing the problem myself instead of adding another bug
> to a QA maintained package seems reasonable.
I like the idea of 's/^(\s*)o\s+/$1* /' (to preserve the leading
indentation, in case this was a second level item) as a preprocessing
step in the interim, in the long term this usage should go down as
policy starts to deprecate it.
> 4. I expect more not yet detected needs for preprocessing.
Thanks for working on this.
> 5. I expect the lintian checks for the markdown format rather
> complicated because there is a lot more freedom in the
> format (which might be an advantage for the editors) and
> some valid markdown input might be successfully rendered
> but into something which conflicts the intention of the
> author. Compared to my suggestion of formating the
> long descriptions according to stricter rules this adds
> another level of complecity while the lintien checks
> which would be needed for my suggestions would have been
> really cheap. I'd consider this as a disadvantage.
> I might note that I'm not happy that in the case of pure and
> simple ASCII output of long descriptions as it is done by current
> tools more or less we will have a rendering which does not fit my
> taste at all - but I accept that I probably belong to a minority
> and if markdown is widely accepted it leads to my initial goal
> (tasks pages) as well.
manoj
--
Hartley's First Law: You can lead a horse to water, but if you can get
him to float on his back, you've got something.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: