At Mon, 27 Aug 2012 14:12:21 +1000, Allan McRae wrote:
On 26/08/12 03:36, Luke Shumaker wrote:
An advantage of my design is that it does allow for integrity checks of VCS packages, rather than inserting 'SKIP' into the md5sums array. This is very important to the derivative distribution Parabola. (However, the 'SKIP' option is still valuable for URLs that track a branch)
Can you explain why this is important? That would help me understand what you are trying to achieve that can not be done with the current system.
The only reason I can see to create a tarball is to distribute the source on its own. Using "makepkg --allsource" creates a full source tarball including the VCS sources. If you are worried about integrity of those VCS sources in the source tarball, adding a checksum to the PKGBUILD does nothing as the PKGBUILD can be edited too. You are best to use "makepkg --allsource" and PGP sign the resulting tarball.
Some of the Parabola devs have a weird fixation with checksums. However, after discussing it with them, your implementation addresses all of their major concerns. My only concern--and this is a minor one--is that if a user uses the fragment to check out a specific commit, with (for example) svn, if that commit changed upstream (which requires wizardry, but does happen), then you have no idea at download time.
But perhaps I entirely missed the issue...
A comment that I need to make is about the need for a separate tool to download the vcs sources. We used to have a script called "versionpkg" that dealt with VCS packages. That got merged into makepkg and my recent work was to fully integrate VCS packaging into makepkg. So going using a separate script to deal with VCS sources is really a step or two backwards.
The difference is that versionpkg was invoked directly by the user, distracting them from makepkg. My `vcsget` tool is simply a downloader-agent. The idea was to reinforce makepkg's paradigm: extract scheme from URL, look for entry in DLAGENTS, use that. The way you've done it, it checks if the scheme is in a list, then checks DLAGENTS if it is, or does a number of special things based on what scheme it is. Given it's simplicity, if we're shoving specialized logic for each scheme into makepkg, why have DLAGENTS at all? Why not just move that collection of one-liners into makepkg? If that's the direction you want to go, that's fine, but I'd wanted to stick to the current paradigm of using DLAGENTS, and having the URLs be basically opaque to makepkg. Thanks for your reply! Happy hacking, ~ Luke Shumaker