[pacman-dev] [PATCH 0/3] makepkg: Alternate implementation of VCS URLs in sources array.

[Luke T.Shumaker]

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