>>>>> "JLT" == Jason L Tibbitts <tibbs@xxxxxxxxxxx> writes:
JLT> Well, I've had this exact discussion at least twice before and
JLT> it's always come down to precisely the scheme I indicated.
Some bits from my IRC logs:
[Sat Aug 12 2006] [22:50:27] <tibbs> Hmmm, why do we mandate a date for the alphatag of an SVN checkout when the tree revision number actually makes more sense?
[Sun Aug 13 2006] [02:13:27] <abadger1999> tibbs: Michael Schwendt explained on the list at one point that the date is portable in case upstream migrates to a different revision control system whereas the revision number is only
applicable as long as they keep using subversion. A proposal was made to use DATEsvnREV# if you wanted to include the rev# information and some people have used that (but I don't think it made it into the official guidelines.)
[Sun Aug 13 2006] [09:13:14] <tibbs> abadger1999: I think that's rather pointless given that you'd just bump the number that comes before the alphatag.
[Sun Aug 13 2006] [09:13:57] <tibbs> It's like arguing that they could switch from SVN to CVS one day, and worrying about the version going backwards because CVS < SVN.
[Sun Aug 13 2006] [10:02:07] <f13> are svn revisions rpmsortable ?
[Sun Aug 13 2006] [10:08:27] <tibbs> Do they need to be?
[Sun Aug 13 2006] [10:08:56] <tibbs> You're supposed to bump the number before the alphatag anyway. So sortability of the alphatag shouldn't make a difference.
[Sun Aug 13 2006] [10:09:33] <tibbs> In any case, they're a monotonically increasing integer. I don't know if that's rpmsortable.
[Sun Aug 13 2006] [10:30:31] <f13> if they increase thats fine
[Sun Aug 13 2006] [10:30:47] <f13> as long as it isn't something with checksums (mercerial)
[Sun Aug 13 2006] [10:41:34] <tibbs> Even then I don't see the problem. It's a string which (supposedly) uniquely identifies the checkout.
[Sun Aug 13 2006] [10:41:47] <tibbs> The number before the alphatag is what imposes the ordering.
[Sun Aug 13 2006] [10:42:15] <tibbs> Using dates is ambiguous in any case; CVS just doesn't provide anything better unless you tag every commit.
[Sun Aug 13 2006] [10:42:45] <tibbs> I don't see why something better couldn't be used for version control systems which provide it (which is pretty much everything except CVS).
[Sun Aug 13 2006] [10:51:22] <f13> tibbs: think of cases were nothing changes but the snapshot number
[Sun Aug 13 2006] [11:00:58] <tibbs> So you bump the number before the alphatag. I don't see the problem.
[Sun Aug 13 2006] [11:01:39] <tibbs> The naming guidelines say that you have to do that every time the snapshot number changes.
[Sun Aug 13 2006] [11:05:15] <f13> do they?
[Sun Aug 13 2006] [11:05:32] <tibbs> I'm looking at the kismet example:
[Sun Aug 13 2006] [11:05:34] <tibbs> kismet-1.0-4.20050515cvs (bugfix to the post-release cvs checkout)
[Sun Aug 13 2006] [11:05:39] <tibbs> kismet-1.0-5.20050517cvs (new cvs checkout, note the increment of %{X})
[Sun Aug 13 2006] [11:05:48] <tibbs> Looks like an increment just because the snapshot changed.
[Sun Aug 13 2006] [11:06:19] <f13> looks like they do yeah.
[Sun Aug 13 2006] [11:06:23] <tibbs> The examples seem consistent in that.
[Sun Aug 13 2006] [11:06:35] <f13> nod
[Sun Aug 13 2006] [11:06:47] <tibbs> It looks like everything expects that the alphatag does not impose a strict ordering.
[Sun Aug 13 2006] [11:06:58] <f13> I don't have really any objections, it'll just get fun if we special case each and every SCM possibility
[Sun Aug 13 2006] [11:10:33] <tibbs> I'm not sure we'd need to.
[Sun Aug 13 2006] [11:11:18] <tibbs> If the SCM in use provides an identifier which uniquely specifies a particular checkout, then use it. There should still be room for common sense.
[Sun Aug 13 2006] [11:11:59] <tibbs> The real problem is that dates don't uniquely identify checkouts.
[Sun Aug 13 2006] [11:12:52] <tibbs> But of course in some cases using dates may just be simpler. SVN is kind of special, I think, because it's the only one that provides a monotonically increasing serial number.
[Sun Aug 13 2006] [11:13:04] <f13> oh boy, I can't wait to see the first package that has a mercerial sha1sum in the release string.
[Sun Aug 13 2006] [11:13:21] <tibbs> Well, a date would be completely useless there in any case.
[Sun Aug 13 2006] [11:14:00] <f13> nod.
[Sun Aug 13 2006] [11:14:14] <tibbs> Nothing we have allows specification of things like branches anyway.
[Sun Aug 13 2006] [11:15:08] <tibbs> So perhaps the point isn't that the date tells you what to check out.
[Sun Aug 13 2006] [11:15:31] <tibbs> (I wasn't around for the original discussion. I can't imagine that this kind of thing wasn't covered already.)
[Sun Aug 13 2006] [11:15:34] <f13> nod, more of when the snapshot was taken.
[Sun Aug 13 2006] [11:15:46] <f13> i wasn't around either.
[Sun Aug 13 2006] [11:16:15] <tibbs> Perhaps it's best to leave additional data like that for comments in the spec file.
[Sun Aug 13 2006] [11:17:30] <tibbs> What's confusing is that the name of the SCM gets put in the alphatag, which makes it look like the date somehow refers to some kind of SCM identifier.
[Sun Aug 13 2006] [11:18:00] <f13> yeah, it was probably not really discussed regarding the other SCMs
[Sun Aug 13 2006] [11:19:46] <tibbs> It's not as if a particular package is going to have more than one upstream SCM.
[Sun Aug 13 2006] [11:20:34] <tibbs> So what's the point of even including it? Just to indicate that it was pulled from the SCM instead of from some released snapshot?
[Sun Aug 13 2006] [11:26:27] <f13> not sure
[Sun Aug 13 2006] [11:26:32] <f13> best would be to ask spot
[Sun Aug 13 2006] [12:57:08] <abadger1999> tibbs: spot would be the only one to know all the reasoning behind the original naming.
[Sun Aug 13 2006] [12:57:18] <abadger1999> Here's mschwendt's post: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00447.html
[Sun Aug 13 2006] [12:58:58] <abadger1999> FWIW I agree that there's supposed to be an integer in the Release: before we get to this portion of the tag but you'll have to ask spot/mschwendt if there's something else going on.
- J<
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
