FS#13407 - add 'patch' as an (opt||make)depend to (abs||pacman)
Attached to Project:
Pacman
Opened by kludge (kludge) - Saturday, 21 February 2009, 20:30 GMT
Last edited by Dan McGee (toofishes) - Monday, 23 March 2009, 22:32 GMT
Opened by kludge (kludge) - Saturday, 21 February 2009, 20:30 GMT
Last edited by Dan McGee (toofishes) - Monday, 23 March 2009, 22:32 GMT
|
Details
a user of 'kernel26parallel' in the aur just pointed out to
me that 'patch' is required by the build() function of the
PKGBUILD, but is not a depend, optdepend, or makedepend[1].
in this case, build() (and thus makepkg) fails because a
required command was not installed.
on the one hand, i think the most technically/policy correct way to handle the situation is to add 'patch' as a makedepend to the PKGBUILD. after all, patch *is* required by build(), but not for any functionality of the built package. on the other hand, there are a *lot* of PKGBUILDs out there that use patch. it seems to be common-enough practice that patching is expected functionality in a PKGBUILD. in that case, i think it would be reasonable to add patch as a dependency of the package that provides makepkg. suggested fixes, in order of complexity (for the arch developers): 1) leave it to package maintainers to include patch as a makedepend if they use patch in build() 2) add patch to the pacman optdepends. pacman provides makepkg, and makepkg's functionality vis-a-vis PKGBUILDs is extended by patch. 3) add patch to the abs depends. since abs provides "utilities to download and work with the Arch Build System (ABS)," and 604 PKGBUILDs in the abs will fail without patch[2]. (additionally, it might make more sense for abs to provide makepkg than pacman. after all, the end-user never *needs* makepkg to successfuly use pacman, but abs is practically useless without it.) [1] http://aur.archlinux.org/packages.php?ID=23467 [2] 'grep -Rl "patch -" $(find /var/abs/ -type f -regex "^/var/abs/.*/PKGBUILD") | wc -l' Additional info: pacman 3.2.2-1 abs 2.3-1 patch 2.5.9-2 |
This task depends upon
Closed by Dan McGee (toofishes)
Monday, 23 March 2009, 22:32 GMT
Reason for closing: Won't implement
Additional comments about closing: Comments make it more clear what our intent of the base-devel group is.
Monday, 23 March 2009, 22:32 GMT
Reason for closing: Won't implement
Additional comments about closing: Comments make it more clear what our intent of the base-devel group is.
This is the solution in use now, and I am not sure it is going to change.
1) because base-devel is a group, and not a proper package, pacman doesn't give any clue to its existence with searches, and it doesn't show up in the package search on the webpage.
2) while base-devel is mentioned all over the wiki on pages relating to makepkg, the aur, and package building, it isn't mentioned once on the main ABS page. i'll be correcting that in just a moment.
3) since the abs is useless without those tools, why not make base-devel a dependency of abs?
4) what's the rationale to providing makepkg via pacman and not abs
i probably ought to move this to a mailing list, since i think the discussion could be productive, but doesn't necessarily belong in a bug-tracker. what say y'alls?
by which i meant, what would be an appropriate venue for this discussion?
2) base-devel should indeed be mentioned as much as possible on the wiki, thanks for helping on that point
3) because it is not a dependency, you can run abs without having base-devel installed. (also note that you could want to have a look at PKGBUILDs without building them, but it's not even the point here)
4) pacman and makepkg are really tied to each other, from a technical point of view. makepkg produces package in a certain format, which pacman must be able to read. Same for repo-add. abs is totally different however, it is basically just a wrapper around rsync to fetch ArchLinux official PKGBUILDs.
2) not a problem. in my perfect world, you shouldn't need to access outside documentation to go from a bare system to a working abs/aur/makepkg setup, but as long as you do, it might as well be correct and comprehensive.
3) good point. what about an optdepends, then? something like:
optdepends=('base-devel: tools needed by makepkg to build binary packages from PKGBUILD files')
4) fair enough... i'm approaching this from a work-flow/interface prespective rather than a technial point-of-view.
considering optdepends=('base-devel: tools needed to build packages')
1) add this optdepends to makepkg
2) add this optdepends to abs
3) do nothing and reject this feature request
In my opinion, the results of
FS#13306could affect this choice, because it could make options 1) and 2) invalid, leaving us with only 3).In that case it also seems logical to add base-devel as a dependency for build system.
1) pacman and makepkg are too integrated to split up. They should be from the once source and as such packaged together.
2) makepkg does not need base-devel. I can run makepkg fine without gcc installed (provided my PKGBUILD does not use gcc)
3) abs is for obtaining Arch PKGBUILDs. Yes it then allows the user to adjust and run makepkg on them, but any package in base-devel is only needed if you do this and the PKGBUILD you use requires them. In fact, abs does even not need makepkg (pacman) as a dep.
So that lead me to the conclusion, base-devel is not a dep anywhere.
So how do we solve this? Ideally, a PKGBUILD should specify everything that is needed to build it from a clean system. However, the decision of what packages a clean system is composed of is the issue. The Arch dev team have decided that for building packages a clean chroot contains base base-devel and sudo. So the decision has been made for a long time - in Arch, you are assumed to have base and base-devel installed if you want to build stuff.
So the valid part of this bug just comes down to documenting the Arch building assumptions better and that has been done.
This is the best way to handle this in my opinion.