PP> Well, I've (a) tried to get the owners to rename the tarball with PP> an embedded version number, so far without success, and (b) went PP> looking through the maintainers wiki on how to handle cases where PP> the tarball isn't versioned (and it must be done manually) but PP> didn't find it. You just deal with it the hard way. CVS (or the sources mechanism, at least) has no problems dealing with unversioned upstream source. The burden on the packager is higher but it's not really all that difficult to deal with. It does make upstream source comparisons mostly useless, though, so we lose an important means of verification but this isn't something the maintainer can solve. If you asked upstream and they don't care then you've done what you can do. - J<

PP> Yeah, about that... they don't seem to be using CVS upstream... PP> If they're using SVN, then they don't publish a public interface. I was talking about our CVS. You can do "make new-sources" with a new tarball that has the same name and the system won't be confused (because it differentiates by checksum). The bottom line is that if upstream doesn't version their tarballs, you can simply upload them to the buildsys and nothing will break. So its really your choice as to whether you want to do some sort of local renaming or not. Personally I wouldn't, since it really doesn't do much good. - J<

IV> Except when you have different versions of Fedora having different IV> versions of the package. I fail to see what difference that makes. Of course you version the package itself. - J<

IV> Won't they conflict in the lookaside cache? No. Check my earlier messages in the thread: files in the lookaside cache are differentiated by checksum. - J<

DL> Still, the lookaside can only keep one version of the tarball DL> right ? No. It differentiates by checksum: one tarball per name/checksum pair. If you alter the tarball without renaming and re-upload it, the old one will still be in the lookaside. I'm not sure what else I can say to convince folks that yes, the lookaside really can handle multiple different tarballs with the same name. Would you like to see the directory structure? It looks like: package-name/ tarball-name/ tarball-checksum1/ tarball-name tarball-checksum2/ tarball-name For example, the auccu pacjkage has a tarball that changed: aiccu_20070107.tar.gz is present with two different checksums: $ ls -R aiccu//aiccu_20070107.tar.gz/ aiccu//aiccu_20070107.tar.gz/: 60c203fa33cad3db9fba2a871e3d9381 67a6d55ef2d6e88a3f17bcb5eec02c61 aiccu//aiccu_20070107.tar.gz/60c203fa33cad3db9fba2a871e3d9381: aiccu_20070107.tar.gz aiccu//aiccu_20070107.tar.gz/67a6d55ef2d6e88a3f17bcb5eec02c61: aiccu_20070107.tar.gz file_dest = "%s/%s/%s/%s/%s" % (my_topdir, NAME, FILENAME, MD5SUM, FILENAME) - J<

On Thu, Aug 28, 2008 at 06:57:03PM -0700, Philip Prindeville wrote: If you are after a date to use as a version number, then use the mtime of the tarball. Get it with wget -N to preserve timestamps (curl has similar options). If the download is broken timestamp-wise (like it is for asterisk/zaptel etc. for example), then use the date of the newest file in the tarball. -- Axel.Thimm at ATrpms.net