FS#16872 - the way VCS packages are handled is a mess

Attached to Project: Pacman
Opened by Rogutės (rogutes) - Wednesday, 28 October 2009, 01:26 GMT
Last edited by Allan McRae (Allan) - Friday, 10 August 2012, 04:54 GMT
Task Type General Gripe
Category makepkg
Status Closed
Assigned To Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.3.2
Due in Version 4.1.0
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

* Different VCS systems are handled differently. The sources are fetched/updated automatically only for hg (if $_hgroot and $_hgrepo are defined) and not the other VCSs. For bzr and svn, only the revision is fetched. For cvs and darcs, the remote repository is not contacted at all. This incosistency is confusing.

* VCS sources should be handled before build(), like the other sources in the $source array or there should be a prepare_sources() function (which could also be useful for patching..).

* VCS sources should land in $SRCDEST and not under $srcdir.
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 10 August 2012, 04:54 GMT
Reason for closing:  Implemented
Additional comments about closing:  https://projects.archlinux.org/pacman.gi t/commit/?id=024bc44a
Comment by Dan McGee (toofishes) - Wednesday, 28 October 2009, 02:00 GMT
Allan, don't we have this stuff in like 3 different places? The recent ML threads along with probably another bug report or two. It might be nice to get a unified place to track this stuff.
Comment by Xavier (shining) - Wednesday, 28 October 2009, 09:05 GMT
We have identified a lot of problems already related to VCS
(also check out the 4 other bug reports : http://bugs.archlinux.org/task/16384#comment50310)

I have another very annoying one related to the first point here : afaik forcever only works for cvs/svn.
It does not seem trivial at all how to handle completely different VCS system in a consistent and unified way. This will probably require some brainstorming.

Then we need to agree on how to fix all these problems, and implement the solutions..
Comment by Lukas Jirkovsky (6xx) - Thursday, 11 March 2010, 12:20 GMT
The problem with mercurial is that there is (most likely) no way how to find out the current revision without doing clone. See: http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-CommonProblems.How_can_I_do_a_.22hg_log.22_of_a_remote_repository.3F
Comment by Rogutės (rogutes) - Thursday, 11 March 2010, 19:14 GMT
Lukas: but you ought to clone if you want to build something, no?
Comment by Lukas Jirkovsky (6xx) - Sunday, 14 March 2010, 08:27 GMT
Rogutės: I was only explaining why mercurial behaves differently than eg. subversion.

Loading...