Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

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
Task Type General Gripe
Category makepkg
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 3.2.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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.
Comment by Xavier (shining) - Saturday, 21 February 2009, 20:40 GMT
4) Expect every user who build package to have the base-devel group installed

This is the solution in use now, and I am not sure it is going to change.
Comment by Dan McGee (toofishes) - Saturday, 21 February 2009, 20:50 GMT
Xavier is 100% correct. We have a whole shitload of packages that fall in this same category, and we don't all put make or gcc in our makedepends either. It just isn't worth it- if you want to build packages, install base-devel.
Comment by kludge (kludge) - Saturday, 21 February 2009, 22:41 GMT
that's understandable and sensible enough. however, having just looked around, i'd like to make a few comments, if only just for the record.

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?
Comment by kludge (kludge) - Saturday, 21 February 2009, 22:46 GMT
"what say y'alls"

by which i meant, what would be an appropriate venue for this discussion?
Comment by Xavier (shining) - Saturday, 21 February 2009, 22:57 GMT
1) why would you search for base-devel? If you already know that name, you should know it's a group, then you can do "pacman -Sg base-devel" to see its content.

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.
Comment by kludge (kludge) - Saturday, 21 February 2009, 23:17 GMT
1) b/c i didn't remember ever having installed it. i was curious, especially about how a user who wanted to compile a custom kernel didn't have patch installed. so i tried to figure out how you'd know what you needed if you didn't already know you needed it. if you don't already know about base-devel, you won't learn about it with the tools already on your system. that's a limitation in my mind; i like my systems closed.

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.
Comment by Dan McGee (toofishes) - Saturday, 28 February 2009, 19:12 GMT
Where are we going with this?
Comment by Xavier (shining) - Saturday, 28 February 2009, 19:20 GMT
I see three possibilities :

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#13306  could affect this choice, because it could make options 1) and 2) invalid, leaving us with only 3).
Comment by Val L. (onestep_ua) - Sunday, 01 March 2009, 14:38 GMT
Let me also vote for moving makepkg to the abs package. Since pacman is a PACkage MANager, and ABS is an Arch Build System, this seems logical to install build tool with build system, and not with package manager. After all, makepkg is also just a wrapper around PKGBUILD, which is often just a wrapper around configure / make / make install. :)
In that case it also seems logical to add base-devel as a dependency for build system.
Comment by Val L. (onestep_ua) - Sunday, 01 March 2009, 14:47 GMT
BTW, http://wiki.archlinux.org/index.php/ABS contains references to makepkg as an ABS-related program.
Comment by Xavier (shining) - Sunday, 01 March 2009, 14:48 GMT
We already understood this point of view. But if you don't understand the opposite one and just ignore it, this discussion is not going anywhere...
Comment by Val L. (onestep_ua) - Sunday, 01 March 2009, 16:16 GMT
You're not right, I'm not ignoring it. I've just added some pros of moving makepkg to abs and will be happy to see some cons, if you point me to them. All that I noticed is that makepkg produces packages in pacman-understandable format, maybe I've missed something else.
Comment by Dan McGee (toofishes) - Sunday, 01 March 2009, 16:40 GMT
What you've missed is ABS is Arch-specific, while pacman and makepkg are not. We try very hard to leave the option open for pacman and makepkg to be ported to other platforms, and we have a lot of people that want to use it on OS X, for instance. pacman is rather useless without makepkg, as you will have nothing to install.
Comment by Val L. (onestep_ua) - Sunday, 01 March 2009, 19:42 GMT
Okay, that's a very clear answer. :) Sorry for being ignorant on that.
Comment by Allan McRae (Allan) - Sunday, 01 March 2009, 20:19 GMT
I have just read all this an my conclusion is that we should do nothing...

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.
Comment by Gavin Bisesi (Daenyth) - Friday, 20 March 2009, 14:23 GMT
> 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.

Loading...