Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#20217 - [makepkg] list dependencies explicitly: two suggestions

Attached to Project: Arch Linux
Opened by Xyne (Xyne) - Monday, 19 July 2010, 00:51 GMT
Last edited by Allan McRae (Allan) - Friday, 16 November 2012, 11:28 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.4.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

Hi,

Currently makepkg simply assumes that the "base" and "base-devel" groups have been installed and that its dependencies are satisfied. This might be common but in environments such as minimal chroots there is no reason to install those groups when only a few packages are actually required to satisfy makepkg's dependencies. Users who do not wish to install unnecessary packages must therefore determine makepkg's actual dependencies themselves, which contrasts with how all other packages are packaged (i.e. users are not expected to inspect source code to determine the dependencies of other packages).

Makepkg explicitly lists its dependencies near the top of the file:

# makepkg uses quite a few external programs during its execution. You
# need to have at least the following installed for makepkg to function:
# bsdtar (libarchive), bzip2, coreutils, fakeroot, find (findutils),
# gettext, grep, gzip, openssl, sed, tput (ncurses), xz


"file" should also be included on that list, and perhaps some others that have been missed. I've already notified the pacman development team about "file".

I have two suggestions:


Suggestion 1: list makepkg's dependencies as explicit optional dependencies in the pacman package. To facilitate their installation, they could be grouped as "makepkg-deps" or something similar, or maybe even replace "base-devel" and allow anything else currently in the "base-devel" group to be specified explicitly as a "makedep" for packages that require it, but that is a tangential suggestion.


Suggestion 2: split the current pacman package into "pacman" and "makepkg". This makes sense because makepkg is useless without the additional dependencies and it would simplify dependency management for makepkg. I would prefer this over the optdeps approach because pacman doesn't actually handle optdeps now, although this may change in the future.



The underlying argument is that it goes against the Arch philosophy of minimalism and customization to expect users to install a myriad of "standard" packages and then simply assume that they exist on the system whether or not they are needed. Arch neither requires nor assumes any particular minimal installation so it's strange that a key component of its packaging system does.

Regards,
Xyne
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 16 November 2012, 11:28 GMT
Reason for closing:  Won't implement
Comment by Allan McRae (Allan) - Monday, 19 July 2010, 06:10 GMT
For as long as I have as I have been using Arch, when packaging it is assumed that the "base" and "base-devel" groups are installed so they do not need to be listed as makedepends. So the minimum packages "required" to build a package (using a PKGBUILD from ABS/AUR) and hence run makepkg is these two groups. This means that tradition dictates this as not a bug...

However, I do like packages to have dependencies correctly listed. Options:
1) add as deps to the pacman package
2) add as optdeps to the pacman package
3) split makepkg

1) is not going to happen as pacman's deps should be minimal. 2) seems weird to me as that is a lot of optdeps and optdeps currently do nothing. 3) is not ideal as the pacman makefile is not designed to install those separately.

Even if we do #3, what do we do about repo-add/pkgdelta's requirements?
Comment by Xyne (Xyne) - Monday, 19 July 2010, 06:28 GMT
Tradition dictates a lot of things that are wrong. ;)

I agree with your points concerning 1 & 2 and I think 3 is the best option. Not all users need makepkg and it is the simplest approach to dependency resolution. I have a feeling that the upstream devs can be convinced to update their makefile. ;)

repo-add and pkgdelta could be left in the pacman package with their deps listed as optdeps (How many are there?). They are both tools for working with existing packages like pacman, as opposed to makepkg which is for creating new packages, but that argument is tentative.
Comment by Xavier (shining) - Monday, 19 July 2010, 11:30 GMT
Why would you use repo-add for a package you did not build yourself ?

If you bothered to look at our source tree, you could see that we already have a logical split there. The scripts are in ... scripts :
http://projects.archlinux.org/pacman.git/tree/scripts

If arch philosophy was to waste hours for not installing a few deps today that you might need tomorrow, I don't know if I would use it. Fortunately, Arch is not about that :) Actually Arch philosophy has nothing to do with minimalism.

It's simpler/easier to just put "base-devel" group rather than listing every deps explicitly. It's also easier to not split packages in the smallest logical unit possible, that needs more work and complexity. So your view of Arch philosophy is completely opposite to mine :)
Actually the introduction of the split feature shows that Arch is not strict, it sometimes brings some needed complexity to the system.

That said, I am not against having more precise dep list and split packages if people are willing to take the time to do that.
And if one has the choice between using optdeps and splitting a package, well just split it, it's much cleaner and nicer for the user. But it's definitely not simple.
Comment by Xyne (Xyne) - Monday, 19 July 2010, 12:54 GMT
repo-add can be used to create LAN mirrors to avoid external downloads or preserve packages that are no longer available in the repos.


By your reasoning, it's simpler/easer to just install Xorg as most people will use it. You could even extend that to some of the basic window managers, but that's irrelevant to the point.

The point is Arch packages are supposed to specify their hard dependences as "depends" and other dependencies as "optdepends". It doesn't make sense that the package manager package itself disregards these rules and that makepkg simply assumes that 79 packages are installed, even if it's written in the wiki and elsewhere that one should have them. In my case, I need to build packages in a minimal chroot. There is no reason at all to install all 79 of those packages. Typing "pacman -S base base-devel" might be simpler than figuring out the actual dependencies, but "pacman -S makepkg" or "pacman -S makepkg-deps" would be just as simple and much more in line with Arch's minimalism (which is a part of Arch... a simple.lightweight Linux distribution).

I posted 2 suggestions. The first was to group makepkg's hard dependencies and includes those as optdeps, either listed simply as a group or individually, but optdeps are currently useless... they're really just suggestions in the PKGBUILD.

The second, to split out makepkg, makes sense for handling dependencies. It might not be Arch's general policy to split packages, but in cases where upstream includes distinct and independent applications in one package, it is reasonable and it is exactly what the splitpackage functionality is for.

In either case all I really want is a way to cleanly install makepkg's dependencies without installing unnecessary packages. The first suggestion would provide that information and hopefully one day pacman will be able to handle optdeps. The second suggestion would let pacman handle it automatically, which is what it's supposed to do.
Comment by Allan McRae (Allan) - Wednesday, 21 July 2010, 04:39 GMT
The way the pacman source is currently set out, a "make install-makepkg" target really makes no sense. Without such a target, splitting the package will be quite ugly...

However, if makepkg becomes split up into a bunch of libraries that it calls, then it will make more sense to have makepkg and its library functions all in their own directory tree and moved out of the "scripts" directory. Such a change would be good for makepkg (it is becoming difficult to maintain with all functions in one file) and probably has to occur before we can do a complete overhaul on how VCS packages are handled. It would also make the splitting of translations for makepkg out of the pacman file (which I think needs done...) better.

I vote we defer splitting until this happens. Note that such a change in makepkg is not on my radar for things to get done for pacman-3.5 (or anyone else's that I know of) so it may be a while.
Comment by Allan McRae (Allan) - Wednesday, 06 October 2010, 13:56 GMT
Unassigning me as keeping me in the assignees only serves to instil a false sense of optimism that I am ever going to do something about this... I will leave it to the pacman package maintainer to make the decision.
Comment by Dan McGee (toofishes) - Wednesday, 06 October 2010, 14:10 GMT
I'm not sure assigning this to me is any better here- I'm definitely kept busy by bigger projects that need tackling in pacman at the moment and I just don't have a strong opinion one way or the other here. I am also much less likely to do anything on a bug that provides no patches or work. Step one here would at least seem to be providing a patch that makes install a bit more flexible; honestly autotools might already be providing some help here but I haven't looked enough.
Comment by Karol Błażewicz (karol) - Wednesday, 04 July 2012, 19:01 GMT
https://wiki.archlinux.org/index.php?title=Beginners%27_Guide/Installation&diff=prev&oldid=200526 says "There is no requirement that all of base must be installed" but https://wiki.archlinux.org/index.php/Makepkg#Usage still says "remember that the base group is assumed to be installed on all Arch Linux systems."

Loading...