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 li
On Thu, May 12, 2011 at 02:25:06AM +0200, Guillem Jover wrote:
>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 t
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
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
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
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
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
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 Po
On Mon, 02 May 2011, Charles Plessy wrote:
> 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 w
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
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
On Sat, 30 Apr 2011, Russ Allbery wrote:
> Osamu Aoki 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 says that
Osamu Aoki 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 requirement
Hi,
On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote:
> Ben Hutchings writes:
>
> > +
> > + 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
On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote:
> Ben Hutchings writes:
>
> > +
> > + 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 versi
Ben Hutchings writes:
> +
> + 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 information may be rec
Ben Hutchings (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 --git a/pol
---
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 --git a/policy.sgml b/policy.sgml
index 91173a5..2cc2d1e 100
18 matches
Mail list logo
