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

Re: [PATCH] Specify policy for use of revision IDs in version numbers


On Sun, 2011-05-01 at 17:27:39 +0200, 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.

dpkg -l only truncates the output on terminals, and then only if the
width is not enough to display the whole thing. aptitude seems to be
truncating always the version to 10 characters, regardless of terminal

> > 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 canonical packages names. Packages filename can be mangled
> to fit the medium, there is a program 'dpkg-name' to recover the
> canonical packages name.

Exactly, we could also add a new option to dpkg-name to select which
naming layout to use, for example:


or something along these lines. Currently dpkg-split already has a
--msdos option to generate a 8.3 filename for the split files, which
could be deprecated in favour of dpkg-name instead.

> This requires the same mangling to be applied
> to the filenames in the Packages files, but this not an issue since the
> Packages file is in the same medium.

Well, this has already been solved long time ago, although the
restrictions were different then, the dselect methods have supported
the MSDOS-Filename field as a fallback to the Filename one. So the
Packages file is usable not only for CDs/DVDs.

The problem is that it seems that most (at least apt, cupt and smart) of
the other front-ends do not support such field, so support would need
to be added first. At that point the field could be named more
appropriately I guess. I'm adding this to the things to discuss with
dpkg front-end developer.


Reply to: