Re: [PATCH] Specify policy for use of revision IDs in version numbers
Hi,
On Mon, May 02, 2011 at 06:20:14PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 01 May 2011, Bill Allombert wrote:
> > On Sat, Apr 30, 2011 at 09:00:14PM -0700, Russ Allbery wrote:
> > > So the reason for imposing a length restriction on version numbers in
> > > particular is due to the UI display of aptitude? I'm a bit dubious that
> > > this is a good justification for a Policy rule. dpkg -l has truncated
> > > version numbers for forever at 14 characters, and I don't recall this
> > > being a major issue in the past. The thing that started off this thread,
> > > I thought, was the constraint on file name length in ISO images, which is
> > > the total length and doesn't impose a constraint specifically on the
> > > version.
> > Also there are no technical requirement for packages filenames in ISO images to be
If you frame question in this way, it is true anything fit within total
file name length of 90 or even more are *technically* OK.
But my thought was a bit different. What kind of package meta data we
would like to generate for version or package name as human interface?
For similar issue, in policy, we have:
| 3.4.1 The single line synopsis
|
| The single line synopsis should be kept brief - certainly under 80
| characters.
I do not think going over 80 for the single line synopsis *technically*
breaks anything these days. But it is good to have some restriction with
"should" in policy to keep human interface of data to be reasonable one.
(not "must")
I presented some UI display info as a reference point of common sense
expectations by the human user. More important data was the cumulative
package % which fits into the length as I presented. These are only
data points for discussion. We are producing very long version and
package name strings for some packages (although they are still in small
number).
Question is should we put cap on obscenely long version or package names
in Policy?
I say, yes please.
Osamu
Reply to: