FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-26-2011, 02:24 AM
Henrique de Moraes Holschuh
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Tue, 26 Apr 2011, Adam Borowski wrote:
> Telling someone "the bug is in a version I pulled from the VCS but didn't
> bother noting down which version it was" is not very useful.

Now you're being silly.

All you need is the proper date and time to use as a version (for
ordering), and a proper debian/changelog entry:

* New upstream source (git://blah, commit "blah: did something",
[#12030a47ebafdcd]).

I.e. the best current practice. How surprising. Now you either tell
upstream when you checked out his tree (and he can locate the commit by
date/time), or look the hash in debian/changelog and tell him that, and
he might be able to locate the commit even on rebased trees.

Kindly recall we need to limit version string lenght a _LOT_ and will be
doing that shortly one way or the other. $(git describe) is out right
there: it cannot be trusted to fit unless you're just using it to get a tag
with a known to be short pattern, which is not what this is about.

And you certainly should not waste 32 chars for the entire hash since it
is unordered and you need space before it for ordering, and space after
it for all the other stuff we tack at the end, so even that is out.

> > If your upstream is pulling such tricks then you cannot use this type of
> > version *with or without* the hash, because it will not be ordered
> > properly. You would have to use a date/timestamp.
>
> Eh? It is exactly why the hash is there!

No, it isn't. The *FULL* hash is there to identify a commit in that
repository to the VCS. It is certainly not there to identify a release to
human beings or distro packaging systems.

And since the hash is NOT fit for such a job in the first place, you have to
supplement it with ordering for it to become meaningful for release
identification ("which one is newer?"), and we don't have space for all that
stuff in the version string.

Also, it IS worth reminding all that git-describe output has *NO* forward
uniqueness guarantees: for that it would have to always use the full hash,
and even that could break should we be forced to drop sha1 for something
longer.

It also cannot be used [safely] to locate commits that were rebased (and
neither can the hash). So, again, you're down to the full hash, and even
that is not good enough by itself [it is not future-proof when a rebase is
not impossible].

> No matter how many commits were done at a particular date, and whether the
> commit was cherry-picked, rebased or tossed around in other ways, a hash
> will let you tell which exactly version it is.

At one point in time, which is not relevant anymore (a rebase happened), and
the object the hash used to point to might have been lost (garbage
collection).

You're either supposed to not rebase anything that is ever made public, or
to identify a commit by its title when it is unique enough, otherwise by
(author, date, title).

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110426022453.GA6256@khazad-dum.debian.net">http://lists.debian.org/20110426022453.GA6256@khazad-dum.debian.net
 
Old 04-26-2011, 05:34 AM
Uoti Urpala
 
Default limits for package name and version (MBF alert: ... .deb filenames)

Henrique de Moraes Holschuh <hmh <at> debian.org> writes:
> On Tue, 26 Apr 2011, Adam Borowski wrote:
> > Telling someone "the bug is in a version I pulled from the VCS but didn't
> > bother noting down which version it was" is not very useful.
>
> Now you're being silly.
>
> All you need is the proper date and time to use as a version (for
> ordering), and a proper debian/changelog entry:
>
> * New upstream source (git://blah, commit "blah: did something",
> [#12030a47ebafdcd]).
>
> I.e. the best current practice. How surprising. Now you either tell

Using date and time as a version is not current best practice. You'll still need
the upstream version part too to sort correctly relative to released versions.
So you'll have the latest upstream version tag, followed by a long timestamp.
That's no shorter than typical 'git describe' output, just a lot less functional.

> upstream when you checked out his tree (and he can locate the commit by
> date/time), or look the hash in debian/changelog and tell him that, and
> he might be able to locate the commit even on rebased trees.

It's naive to think that identifying revisions by timestamp would be that simple
when dealing with distributed revision control systems. There are at least 3
different timestamp types that are relevant to git:

1) The closest analogue to traditional "svn2005...." versions would be the time
when the commit appeared in a certain branch on a canonical central server.
However, information about when the commits were pushed to a particular server
is not stored in the repository history. Thus this form cannot be used for DVCS.

2) The author timestamps stored in commits are the timestamps most prominently
displayed by various tools. However they're not ordered as those timestamps can
come from commits cherry-picked in arbitrary order.

3) The stored committer timestamps are the most realistic alternative, but still
not a good one. If there is only a single relevant "master" branch from which
packaged versions will be taken, history of that branch is never modified, and
everyone creating commits sets the timestamps accurately, then in that case they
will be ordered. But they don't match the time when the changes were publicly
visible, and even less when they were available in that particular master
branch. Also one-second accuracy in version timestamps would not be enough to
identify a particular revision. Cherry-picking, rebasing or applying a series of
mailed patches can create a long run of closely spaced committer timestamps very
rapidly (and rebasing here can be before the changes are first made public, so
would occur in projects that do not modify public history).

Your above "tell upstream when you checked out his tree and he can locate the
commit by date/time" would only work properly for timestamps of type 1). But
that's not an at all realistic alternative.

What you wrote about identifying branches in your other mail ("and you already
know which branch of which tree because that information must be available and
up-to-date in debian/copyright") is also wrong or at least meaningless. Maybe
you'll know that the code was available on the project's public repository under
the branchname "fixes-for-debian" at the time it was downloaded. But what good
will that information do for you later, if the contents of that branch were
merged to another and the obsolete branch name then deleted two days after being
created? In the typical case branch names are not persistent information.


> Also, it IS worth reminding all that git-describe output has *NO* forward
> uniqueness guarantees: for that it would have to always use the full hash,
> and even that could break should we be forced to drop sha1 for something
> longer.

That's wrong in several ways. Even if a hash prefix of the length included in
'git describe' output stopped being unique at some point in the future there
isn't much risk of real confusion (or would you really be unable to tell whether
it's the version from around now or the one from 3 years in the future that's
meant?). And the overall version would still be unique if the tag part changed
before then. "Have to always use the full hash" is wrong; there's no magic
property which makes the hash unique at exactly the full length, that's just the
maximum possible you can take (shorter prefixes will be unique in practice). And
moving from sha1 to something else would not have to invalidate the uniqueness
properties of existing sha1 hashes.


> > No matter how many commits were done at a particular date, and whether the
> > commit was cherry-picked, rebased or tossed around in other ways, a hash
> > will let you tell which exactly version it is.
>
> At one point in time, which is not relevant anymore (a rebase happened), and
> the object the hash used to point to might have been lost (garbage
> collection).
>
> You're either supposed to not rebase anything that is ever made public, or
> to identify a commit by its title when it is unique enough, otherwise by
> (author, date, title).

If the history was modified and the revision Debian used does not exist in
upstream history any more that's certainly important information in itself. A
timestamp might fool you into thinking that the Debian version corresponds to a
particular commit in the upstream repository - a potentially very dangerous
misunderstanding. A hash will prevent such confusion.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: loom.20110426T062535-615@post.gmane.org">http://lists.debian.org/loom.20110426T062535-615@post.gmane.org
 
Old 04-26-2011, 11:02 AM
Henrique de Moraes Holschuh
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Tue, 26 Apr 2011, Uoti Urpala wrote:
> Henrique de Moraes Holschuh <hmh <at> debian.org> writes:
> > On Tue, 26 Apr 2011, Adam Borowski wrote:
> > > Telling someone "the bug is in a version I pulled from the VCS but didn't
> > > bother noting down which version it was" is not very useful.
> >
> > Now you're being silly.
> >
> > All you need is the proper date and time to use as a version (for
> > ordering), and a proper debian/changelog entry:
> >
> > * New upstream source (git://blah, commit "blah: did something",
> > [#12030a47ebafdcd]).
> >
> > I.e. the best current practice. How surprising. Now you either tell
>
> Using date and time as a version is not current best practice. You'll still need
> the upstream version part too to sort correctly relative to released versions.

I was refering to the full commit description in the debian/changelog
entry.

The best current practice for date/time-based versioning is described in
official Debian documentation already, both it and shorter variants (such
as using unix time) have already been mentioned in this thread.

> So you'll have the latest upstream version tag, followed by a long timestamp.
> That's no shorter than typical 'git describe' output, just a lot less functional.

It is *bounded*, and it can be a LOT shorter.

> It's naive to think that identifying revisions by timestamp would be that simple
> when dealing with distributed revision control systems. There are at least 3
> different timestamp types that are relevant to git:

[...]

> Your above "tell upstream when you checked out his tree and he can locate the
> commit by date/time" would only work properly for timestamps of type 1). But
> that's not an at all realistic alternative.

You have the full commit info in the changelog, where you can specify
branch, etc. when best practice is being followed. Use it.

And you can certainly tell your upstream what sort of date you used, if
you're not smart enough to use the commit date of the top commit, which is
the "date that branch was last modified". If that is useless to
upstream, either you know and you tell them the full info from the
debian/changelog right at first, or they complain and you reply with the
full info from debian/changelog.

> What you wrote about identifying branches in your other mail ("and you already
> know which branch of which tree because that information must be available and
> up-to-date in debian/copyright") is also wrong or at least meaningless. Maybe
> you'll know that the code was available on the project's public repository under
> the branchname "fixes-for-debian" at the time it was downloaded. But what good
> will that information do for you later, if the contents of that branch were
> merged to another and the obsolete branch name then deleted two days after being
> created? In the typical case branch names are not persistent information.

It is at least as future-proof as hashes. If your upstream is messy and
likes to rebase and lose past history, only the full commit info
(hash+author+title, etc) you are supposed to have added to the
debian/changelog might help locate it if that commit still exists in a
meaningfull way.

> > Also, it IS worth reminding all that git-describe output has *NO* forward
> > uniqueness guarantees: for that it would have to always use the full hash,
> > and even that could break should we be forced to drop sha1 for something
> > longer.
>
> That's wrong in several ways. Even if a hash prefix of the length included in
> 'git describe' output stopped being unique at some point in the future there
> isn't much risk of real confusion (or would you really be unable to tell whether
> it's the version from around now or the one from 3 years in the future that's
> meant?). And the overall version would still be unique if the tag part changed
> before then. "Have to always use the full hash" is wrong; there's no magic
> property which makes the hash unique at exactly the full length, that's just the
> maximum possible you can take (shorter prefixes will be unique in practice). And
> moving from sha1 to something else would not have to invalidate the uniqueness
> properties of existing sha1 hashes.

The length of the shortened hash used in git-describe is verified for
uniqueness only when generated (if at all). Unless specifically
configured, it will be short enough that colisions *on the shortened hash*
have been observed in practice to be likely on very large projects. That
is why git has already been modified so that you can configure it to, e.g.
never use less than 15 digits of the hash. The rest of the git-describe
output has no inerent strong guarantees of uniqueness, that's why the hash
is added in the first place. It could well be unique if your upstream
never rewinds/rebases, uses only one public branch, and it could be
bounded if she tags often and always has simple history. Or it could
not.

If you have a proper base-version from a tag, you will likely want to use
it, something else for ordering, and then you are out of space for a long
hash anyway.

Full hash colisions are impossible, because, well, the basic constraints
the VCS depends upon *BREAKS* when that happen. That commit never gets
accepted into the repository because the VCS aborts/abends. You try
again, get a different commit date/time and thus a different hash, the
colision condition is gone if you're lucky enough not to get a new one,
and life continues. I really should not have to explain *THIS*.

And this is not about uniquely identifying upstream releases, and it has
NEVER BEEN. That's what debian/changelog and debian/copyright is for.
It is about something good enough for the *package version string*, which
has MUCH stricter requirements, including a fairly draconian length, and
an absolute ordering requirement.

> > > No matter how many commits were done at a particular date, and whether the
> > > commit was cherry-picked, rebased or tossed around in other ways, a hash
> > > will let you tell which exactly version it is.
> >
> > At one point in time, which is not relevant anymore (a rebase happened), and
> > the object the hash used to point to might have been lost (garbage
> > collection).
> >
> > You're either supposed to not rebase anything that is ever made public, or
> > to identify a commit by its title when it is unique enough, otherwise by
> > (author, date, title).
>
> If the history was modified and the revision Debian used does not exist in
> upstream history any more that's certainly important information in itself. A
> timestamp might fool you into thinking that the Debian version corresponds to a
> particular commit in the upstream repository - a potentially very dangerous
> misunderstanding. A hash will prevent such confusion.

0. This is about package versioning;
1. You do not have space for the full hash in the version string;
2. such hash alone is useless for the packaging system in the first place,
it does not work as a package version by itself at all;
3. the shortened hash is of limited value for "upstream identification"
purposes when things get difficult, and wastes precious space;
4. you're supposed to put lots of meta information about the top commit in
the changelog to actually have something that is guaranteed to work well
for "upstream identification" purposes. That includes the full hash and
more;
5. using unbounded methods of identifying the upstream release is never
going to be a best practice because you have to manually check it every
time to not have exceeded the maximum length and when it does, you
will have to fudge it and break the pattern anyway.

What's so difficult to grasp, here?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110426110254.GA31356@khazad-dum.debian.net">http://lists.debian.org/20110426110254.GA31356@khazad-dum.debian.net
 
Old 04-26-2011, 01:28 PM
Osamu Aoki
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Mon, Apr 25, 2011 at 04:07:11PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 26 Apr 2011, Chow Loong Jin wrote:
> > On 26/04/2011 01:50, Gunnar Wolf wrote:
> > > Anyway - Summing up what I'm saying here, tags have a clear meaning: A
> > > point where upstream wants us to base our efforts at, mid-devel-cycle
> > > breakage should be at a minimum. So, instead of basing our packages
> > > off arbitrary commit hashes, why not basing them off tags? I do not
> > > believe it is unreasonable to request upstreams to do some tagging...
> >
> > Because, some times, upstreams don't release at all. See clutter-sharp for a
> > good example of an upstream with not a single tag or release. For the record,
> > I've requested an actual release multiple times before falling back upon
> > packaging a git snapshot.
>
> Then, you use UTC date+time, that's two digits for the best-practice leading
> of "0.", plus 13 digits for YYYYMMDDTHHMM, which is quite precise enough
> most of the time. Add two more for seconds, and it is almost always precise
> enough to identify the head commit in a branch, and you already know which
> branch of which tree because that information must be available and
> up-to-date in debian/copyright. That still leaves enough space for the
> debian revision, security updates, bin-NMUs, NMUs and backporting.

http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1
... four-digit year first, followed by a two-digit numeric month,
followed by a two-digit numeric date, possibly with punctuation between
the components.

digits parts are:
YYYYMMDD or YYYY.MM.DD as I understood this policy.

The aptitude command displays only 10 digits. HHMM may be too much.
(package name up to 30 too)

Although I did not find note "prepending 0. as best practice", it looks
to be a good idea for upstream version.

But, aptitude displays only 10 digits. While about 83% of package have
less than one digit Debian revision, this only leave us with 8 digits.
Even 0.YYYYMMDD becomes 0.YYYYMMDD-1 and 12 digits. No easy solution
here. I guess when YYYYMMDD was proposed, they did not think to put 0.
before them. In this sense, most reasonable solution seems to me

0.YYMMDD

This way, when ever upstream decide to release package with sane
versioning (usually bigger than 1.) within 8 chars and we can continue
without epoch. But this is not documented anywhere.

I guess policy was assuming to use epoch thus recommending to use
YYYYMMDD only. What is the consensus on the best practice. I am abit
confused here.

> And you can supplement the version information with the full commit hash and
> even the repo path in the debian/changelog entry for the upload.

Yes. I agree.

Osamu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110426132806.GA8366@debian.org">http://lists.debian.org/20110426132806.GA8366@debian.org
 
Old 04-26-2011, 11:22 PM
Uoti Urpala
 
Default limits for package name and version (MBF alert: ... .deb filenames)

Henrique de Moraes Holschuh <hmh <at> debian.org> writes:
> On Tue, 26 Apr 2011, Uoti Urpala wrote:
> > Using date and time as a version is not current best practice. You'll still
> > need the upstream version part too to sort correctly relative to released
> > versions.
>
> I was refering to the full commit description in the debian/changelog
> entry.

You were talking about selecting version strings AND adding a changelog entry.
I very clearly addressed the version part.

> The best current practice for date/time-based versioning is described in
> official Debian documentation already, both it and shorter variants (such
> as using unix time) have already been mentioned in this thread.

This branch of the thread was NOT about packages that use date ONLY. Maybe
that's what you were confused about above? The version would still need the
last release name too, as in 15.3.2~rc3+svn20050101120000.

>
> > So you'll have the latest upstream version tag, followed by a long
> > timestamp. That's no shorter than typical 'git describe' output, just a
> > lot less functional.
>
> It is *bounded*, and it can be a LOT shorter.

Typically it is not a "LOT" shorter. And as I explained in the part you
snipped, a timestamp with one-second precision may not be enough to
adequately identify a version in some not-particularly-rare use cases.


> > Your above "tell upstream when you checked out his tree and he can locate
> > the commit by date/time" would only work properly for timestamps of type
> > 1). But that's not an at all realistic alternative.
>
> You have the full commit info in the changelog, where you can specify
> branch, etc. when best practice is being followed. Use it.

If you have recorded the exact hash that will work (of course!). But what you
were saying about timestamps would not work.


> And you can certainly tell your upstream what sort of date you used, if
> you're not smart enough to use the commit date of the top commit, which is
> the "date that branch was last modified".

It's certainly NOT "the date that branch was last modified". If you have
that misconception it perhaps explains why you have problems understanding
some of the issues with timestamps (though I think the explanations in my
previous mail should already have addressed that). The commit date is when
the particular tree/history state at that commit was created. It is NOT
directly associated with any particular branch. It's normal for things to
be first created in local repos, then possibly pushed to a public
development branch, then later after some testing to the master branch;
when these are fast forward merges the timestamp doesn't change even though
each branch changed at a quite different time. If the top commit of the
master branch has a commit timestamp from a month ago that means the branch
could have been modified a minute ago.


> > What you wrote about identifying branches in your other mail ("and you
> > already know which branch of which tree because that information must be
> > available and up-to-date in debian/copyright") is also wrong or at least
> > meaningless. Maybe you'll know that the code was available on the project's
> > public repository under the branchname "fixes-for-debian" at the time it
> > was downloaded. But what good will that information do for you later, if
> > the contents of that branch were merged to another and the obsolete branch
> > name then deleted two days after being created? In the typical case branch
> > names are not persistent information.
>
> It is at least as future-proof as hashes. If your upstream is messy and
> likes to rebase and lose past history, only the full commit info

You're mixing up completely different things. Nothing in my example involved
rebasing or losing history. That's the point: branch names are not a part of
stored history, and can disappear/change even if there is no "messiness".


> The length of the shortened hash used in git-describe is verified for
> uniqueness only when generated (if at all). Unless specifically

I already addressed exactly this in the mail you're replying to.

> Full hash colisions are impossible, because, well, the basic constraints
> the VCS depends upon *BREAKS* when that happen. That commit never gets
> accepted into the repository because the VCS aborts/abends. You try
> again, get a different commit date/time and thus a different hash, the
> colision condition is gone if you're lucky enough not to get a new one,
> and life continues. I really should not have to explain *THIS*.

You really should not try to explain something you clearly have no clue about.
You get a 160-bit hash match, say "damn, bad luck there", change things a bit
and move on? I hope some readers can at least appreciate your explanation for
the comedy value


> 0. This is about package versioning;
> 1. You do not have space for the full hash in the version string;
> 2. such hash alone is useless for the packaging system in the first place,
> it does not work as a package version by itself at all;
> 3. the shortened hash is of limited value for "upstream identification"
> purposes when things get difficult, and wastes precious space;

It's of high value for "upstream identification" purposes when things are
NOT difficult. And it's also of high value in the difficult cases as it'll
normally make it obvious that there ARE difficulties such as changed
upstream history; with only a timestamp you could easily make a dangerous
mistake without realizing there's anything special to watch out for.

> 4. you're supposed to put lots of meta information about the top commit in
> the changelog to actually have something that is guaranteed to work well
> for "upstream identification" purposes. That includes the full hash and
> more;
> 5. using unbounded methods of identifying the upstream release is never
> going to be a best practice because you have to manually check it every
> time to not have exceeded the maximum length and when it does, you
> will have to fudge it and break the pattern anyway.

There's no bounded method that's guaranteed to adequately identify the
upstream revision. If you want to restrict length to a particular limit,
checking that would be easy to automate (you would not need to "manually
check it every time"). On the other hand, checking whether a timestamp
meaningfully identifies a revision is much harder.


> What's so difficult to grasp, here?

I think the main difficulty is that you lack understanding and/or experience
about the practical issues and use cases that can come up in DVCS development.
You clearly lack the needed mathematical understanding to assess hash
uniqueness properties too. Hopefully the people who end up setting Debian
practices will be better informed.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: loom.20110426T233140-621@post.gmane.org">http://lists.debian.org/loom.20110426T233140-621@post.gmane.org
 
Old 04-26-2011, 11:31 PM
James Vega
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Tue, Apr 26, 2011 at 10:28:07PM +0900, Osamu Aoki wrote:
> In this sense, most reasonable solution seems to me
>
> 0.YYMMDD
>
> This way, when ever upstream decide to release package with sane
> versioning (usually bigger than 1.) within 8 chars and we can continue
> without epoch. But this is not documented anywhere.

Why assume the first version will be >= 1.x? It's not uncommon to use
0.x. Using 0~YYMMDD seems a safer option to reduce the chance of
needing an epoch if/when upstream starts using actual version numbers.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 
Old 04-27-2011, 01:52 PM
Steve McIntyre
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Sat, Apr 23, 2011 at 06:31:38PM +0900, Osamu Aoki wrote:
>Hi,
>
>In order to manage package file name length below 90 and to have sane
>screen for package management, may I suggest to recommend some limits
>(for lintian check etc.):
>
> * package name string should be less than 40 characters.
> * version name string should be less than 30 characters.
> (security updates etc. excluded)
>
>Older part of maint-guide text recommend to use 20 or less for package
>name for last 10 years or so. This may be too short for the modern system
>but it is good to have some commonly agreed limits as recommendation.
>
>I will be bumping limit numbers in maint-guide to these.
>
>See below for my rationale with the statistics.
>
>On Thu, Mar 31, 2011 at 01:48:23PM +0100, Steve McIntyre wrote:
>> On Wed, Mar 30, 2011 at 09:54:49AM -0300, Henrique de Moraes Holschuh wrote:
>...
>> >Don't let it go over 250 *bytes* (not characters. UTF-8 and all that...).
>
>Why UTF-8? We should keep it within ASCII so any system can display all
>package file name. In ASCII range, UTF-8 and ASCII are the same byte
>sequence.

We should stick to ASCII, yes. Our original problem (Joliet filename
lengths) shows up again here - Joliet is encoded in UCS-2 for Windows
use, so the limit we're stuck with is ~180 bytes or ~90 characters.

--
Steve McIntyre, Cambridge, UK. steve@einval.com
"This dress doesn't reverse." -- Alden Spiess


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110427135220.GA22634@einval.com">http://lists.debian.org/20110427135220.GA22634@einval.com
 
Old 04-27-2011, 02:26 PM
Osamu Aoki
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Tue, Apr 26, 2011 at 07:31:22PM -0400, James Vega wrote:
> On Tue, Apr 26, 2011 at 10:28:07PM +0900, Osamu Aoki wrote:
> > In this sense, most reasonable solution seems to me
> >
> > 0.YYMMDD
> >
> > This way, when ever upstream decide to release package with sane
> > versioning (usually bigger than 1.) within 8 chars and we can continue
> > without epoch. But this is not documented anywhere.
>
> Why assume the first version will be >= 1.x? It's not uncommon to use
> 0.x. Using 0~YYMMDD seems a safer option to reduce the chance of
> needing an epoch if/when upstream starts using actual version numbers.

Well... I was dreaming and asking the same question last night :-)
For next 88 years, we can do this :-)

Osamu



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110427142631.GA15671@debian.org">http://lists.debian.org/20110427142631.GA15671@debian.org
 
Old 04-27-2011, 03:14 PM
Cyril Brulebois
 
Default limits for package name and version (MBF alert: ... .deb filenames)

Jon Dowland <jmtd@debian.org> (27/04/2011):
> ~ sorts after ., so "0~110427" will be considered newer than "0.1".
> Therefore, the 0 in 0~YYMMDD is meaningless, and would be no better
> than ~YYMMDD (which would still sort after 0.1, and require an
> epoch).

$ dpkg --compare-versions 0~110427 '<<' 0.1 && echo "Jon is wrong"
Jon is wrong

KiBi.
 
Old 04-27-2011, 03:17 PM
Julien Viard de Galbert
 
Default limits for package name and version (MBF alert: ... .deb filenames)

On Wed, Apr 27, 2011 at 04:09:48PM +0100, Jon Dowland wrote:
> ~ sorts after ., so "0~110427" will be considered newer than "0.1". Therefore,
> the 0 in 0~YYMMDD is meaningless, and would be no better than ~YYMMDD (which
> would still sort after 0.1, and require an epoch).
>
From Policy [1], ~*sort before everything, even the empty string...

1: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

Best Regards,
--
Julien Viard de Galbert <julien@vdg.blogsite.org>
http://silicone.homelinux.org/ <julien@silicone.homelinux.org>
GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net
Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6
 

Thread Tools




All times are GMT. The time now is 04:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org