On May 1, 2011 seanius wrote:
On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote:
I don't think it's Policy's place to tell people that they can't use
hashes because they *might* result in long version numbers. They
usually don't.
+1. otherwise, this seems more like a
On Thu, May 05, 2011 at 12:46:15PM +0200, Guillem Jover wrote:
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:
Also there are no technical requirement for packages filenames in ISO
images to be canonical packages names.
Hi!
On Wed, 2011-05-11 at 17:00:17 +0100, Steve McIntyre wrote:
On Thu, May 05, 2011 at 12:46:15PM +0200, Guillem Jover wrote:
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
Hi!
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
Le Mon, May 02, 2011 at 06:09:11PM -0300, Henrique de Moraes Holschuh a écrit :
The commit info varies per upload, it doesn't make sense to modify
debian/copyright at every upload, better have that in the ONE place you must
modify anyway.
I recently started do this regularly for packages I
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
On Sat, 30 Apr 2011, Russ Allbery wrote:
Osamu Aoki os...@debian.org writes:
This is another topic. I do not think everyone agreed yet to a
particular set of numbers. The more I looked into this issue, I think
followings are the possible numbers:
No, but I'd like to have a MUST rule that
Le Sun, May 01, 2011 at 09:42:17AM -0300, Henrique de Moraes Holschuh a écrit :
No, but I'd like to have a MUST rule that says that you MUST specify the
full repository and commit identification data in the 'new upstream'
changelog entry when you package out of a VCS repository instead of a
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
Ben Hutchings b...@decadent.org.uk (30/04/2011):
---
This is based on recent discussions on debian-devel. There was not
complete agreement, but I believe this reflects consensus.
Ben.
policy.sgml | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff
Ben Hutchings b...@decadent.org.uk writes:
+ p
+ The upstream version number must not include a non-linear
+ revision ID or hash, since it cannot help in ordering
+ versions and it tends to result in very long version
+ numbers and filenames. This
On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote:
Ben Hutchings b...@decadent.org.uk writes:
+ p
+ The upstream version number must not include a non-linear
+ revision ID or hash, since it cannot help in ordering
+ versions and it tends to result in
Hi,
On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote:
Ben Hutchings b...@decadent.org.uk writes:
+ p
+ The upstream version number must not include a non-linear
+ revision ID or hash, since it cannot help in ordering
+ versions and it tends to result
Osamu Aoki os...@debian.org writes:
This is another topic. I do not think everyone agreed yet to a
particular set of numbers. The more I looked into this issue, I think
followings are the possible numbers:
* package file name for normal uploads: 90 characters (must)
- rationale: UCS-2
14 matches
Mail list logo
