What I'm going to do: Was: RFC: Description text in packages

Richard Hughes hughsient at gmail.com
Wed Dec 17 11:19:18 UTC 2008


On Wed, 2008-12-17 at 11:01 +0100, Nicolas Mailhot wrote:
> Le Mer 17 décembre 2008 10:49, Richard Hughes a écrit :
> >
> > On Tue, 2008-12-16 at 17:30 -0500, James Antill wrote:
> >>  Personally I think the use of '"', ., *, •, o or ∘ ... are fine,
> >> just
> >> as long as all the tools are displaying the same non-invisible
> >> bytes².
> >
> > Right, this discussion is going nowhere, and there are a lot of egos
> > in play. At the moment I'm thinking PK should just do this:
> 
> So now you are defining a new gnome-PK only syntax that won't work in
> yum, rpm, urpmi, apt, synaptic, gnorpm, yumex, anaconda, LSB rpm, etc
> and will encourage people to produce badly encoded descriptions
> instead of fixing their text.

Ohh, it'll work just fine. In other frontends you'll get:

This is a description, la al la.
List of things fixed:
- one
- two
- three

and in GNOME PK you'll get UTF8 bullets and paragraph unwinding.

> And you can't even be bothered to get it reviewed at the distro level
> (let alone upstream rpm or lsb-side)

No, I'm fed up of being flamed.

> While you are at it, please also integrate a spell and grammar checker
> so users are not exposed to spelling and grammar mistakes and
> packagers do not have to worry about grammar or spell problems.

ROFL.

> Seriously. This stuff is already defined and standardised. You may not
> like what the currebt official choices are, but workarounding them at
> your app level instead of fixing them at the right level (upstream, ie
> in this case in the distro spec files) is not the right thing to do.

* Fri Feb 08 2008  Nicolas Mailhot <nicolas.mailhot at laposte.net>
- 1:1.09-3
⌚ gcc 4.3 rebuild

* Mon Aug 13 2007 Nicolas Mailhot <nicolas.mailhot at laposte.net>
♣ 1:1.09-2
✓ Fix License

So, you've discussed those changes with upstream, defined a set of
enumerated values, and standardised the other spec files right?

I tend to agree with Matthias, markdown
http://en.wikipedia.org/wiki/Markdown seems to be the best compromise,
and I'll adjust my formatter to adhere to this.

Richard.





More information about the devel mailing list