I was working on bug 452636 ( https://bugzilla.redhat.com/show_bug.cgi?id=452636 ), and reached an impasse.
One of my last reviews (from Joe Orton) said:
non-formal review:
is bad - do upstream not provide versioned URLs?
Unfortunately, they do not.
upstream should be educated then ;)
You'll need to work around that and version the tarball manually, I think this is covered in the wiki somewhere.
Well, I've (a) tried to get the owners to rename the tarball with an embedded version number, so far without success, and (b) went looking through the maintainers wiki on how to handle cases where the tarball isn't versioned (and it must be done manually) but didn't find it.
Can someone point me in the correct direction?
Thanks,
-Philip
"PP" == Philip Prindeville philipp_subx@redfish-solutions.com writes:
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<
Jason L Tibbitts III wrote:
"PP" == Philip Prindeville philipp_subx@redfish-solutions.com writes:
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<
Yeah, about that... they don't seem to be using CVS upstream... If they're using SVN, then they don't publish a public interface.
-Philip
"PP" == Philip Prindeville philipp_subx@redfish-solutions.com writes:
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<
On Thu, 2008-08-28 at 21:20 -0500, Jason L Tibbitts III wrote:
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.
Except when you have different versions of Fedora having different versions of the package.
On Fri, 2008-08-29 at 06:55 -0500, Jason L Tibbitts III wrote:
"IV" == Ignacio Vazquez-Abrams ivazqueznet@gmail.com writes:
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.
Won't they conflict in the lookaside cache?
Jason L Tibbitts III wrote:
"IV" == Ignacio Vazquez-Abrams ivazqueznet@gmail.com writes:
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.
Still, the lookaside can only keep one version of the tarball right ?, which would imply all branches of the package must be at the same version also. That doesn't manageable.
"DL" == Denis Leroy denis@poolshark.org writes:
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
From the script that runs when you upload files:
file_dest = "%s/%s/%s/%s/%s" % (my_topdir, NAME, FILENAME, MD5SUM, FILENAME)
- J<
On Thu, Aug 28, 2008 at 09:20:39PM -0500, Jason L Tibbitts III wrote:
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.
I think that it is best left to the packager choice, but in my opinion it helps knowing what source archive is packaged to rename locally and have the timestamp in package name. The downside is that automatic source detection, and automatic download doesn't work anymore.
-- Pat
On Thu, Aug 28, 2008 at 06:57:03PM -0700, Philip Prindeville wrote:
Jason L Tibbitts III wrote:
> "PP" == Philip Prindeville philipp_subx@redfish-solutions.com writes: >
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<
Yeah, about that... they don't seem to be using CVS upstream... If they're using SVN, then they don't publish a public interface.
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.
packaging@lists.fedoraproject.org