Re: [aur-general] Review and a bit of other help request
Hi Konstantin, sorry for not being clear enough for you to understand what I wanted to say. I haven't looked at your PKGBUILD but just tried to give you some hints from where you may be able to find the cause of your trouble. Maybe I should try again ;-) PKGBUILD is just a bash script that is sourced by the bash-script makepkg. So all things true for a bash script are true for PKGBUILD. If a command started by the script is supposed to use some variable from the environment, this variable has to be exported in the script (anywhere in all the files that are sourced by makepkg). So, if make is not able to pick up the variable MAKEFLAGS from the environment, the only explanation is, that the variable is not part of the environment, when make is started. And this is only possible if it was never exported or the export is removed before make is started. And this removal is only possible from the shell that runs makepkg (and have sourced /etc/makepkg.conf and your PKGBUILD). No process started from the script (e.g. cmake, mentioned by you) is able to manipulate the environment of the script! That's all. And now it's your part to use this information and search for the reason, why MAKEFLAGS is not part of the environment, when make is started. In the meantime I have looked into the makepkg script. And there I found these two interesting pieces in run_function: # clear user-specified makeflags if requested if check_option "makeflags" "n"; then unset MAKEFLAGS fi and then # ensure all necessary build variables are exported export CPPFLAGS CFLAGS CXXFLAGS LDFLAGS MAKEFLAGS CHOST So MAKEFLAGS *is* exported and so should be available in the environment of make when started by the script -- *if not* the option "!makeflags" is given, then it always isempty (but exported!). So, if you don't have this option set, there is nothing in makepkg that unsets or unexports MAKEFLAGS and you have to search in all files that are under your control and sourced from the makepkg script. And if you knew all this before, than sorry for bothering, but I have had another impression. Hope this helps Uwe
Re: [aur-general] Should "base" packages be listed as dependencies?
On 2017-03-25 16:31 +0100 Tinu Weber wrote: >On Sat, Mar 25, 2017 at 09:19:43 +0100, Ralf Mardorf wrote: >> On Sat, 25 Mar 2017 06:47:07 +, Xyne wrote: >> >A bash script should depend only on bash. >> >> Hi Xyne, >> >> Seems to be better it would depend on coreutilsor do you asume a bash >> script only depends on bash intern commands and woun't use external >> commands such as e.g. basename? > >In such a case, yes, the application should state that it depends on >coreutils. I don't see an issue, though, other than "I don't want to >type that". I was going to say the same thing before I saw Tinu's reply. My example of a bash script was bad given that most bash scripts will indeed depend on coreutils. coreutils is one of the packages that I think should be assumed in a minimal system btw. >> >It is still up to the user to decide which packages to install even if >> >base is recommended. If you don't use nano or lvm, there is no need to >> >install those packages, for example. >> >> A user always is allowed to customize the install. On my install are >> even some hard dependencies missing, but on another software level, >> not on the base level. The Arch community needs to share some base >> system. If we wouldn't, we wouldn't need Arch related mailing lists. >> There must be something in common to call Arch "Arch". > >I don't think that the Arch community or the OS itself is solely defined >by an arbitrarily selected set of packages that are expected to be >installed. After all, the systems still share the package manager and >the origin of the packages (created and provided by Arch devs) + the >general idea of KISS (e.g. upstream as unpatched as possible, no partial >upgrade support, ...) > >I think some people are mixing up these two things: > >1. Packages that are expected to be there to guarantee a minimally > working system in most situations. >2. Packages that are expected to be there to provide a minimally > comfortable working environment to the user. I agree that people are mixing up two things but I would say that they are 1. Dependency resolution. 2. What constitutes a minimal Arch Linux system. The second is arbitrary. There is no obvious definition, and it doesn't even matter with regard to the first. Explicitly providing the necessary metadata will always work and makes no assumptions. This will benefit all users but forces a few packages to type a few extra words. Assuming (and thereby effectively requiring) that an arbitrary set of packages are installed, even when many of those are unneeded, is a philosophical wart for a minimalist distro that leads to wasted bandwidth and disk space, or broken dependency resolution in some common use-cases. I am actually surprised that there is even an argument for requiring a base system with packages that many users will never need (and the whole "but anyone 'competent' enough to remove some of those packages can manage their own deps manually" is not a valid argument: the distro should not make things more difficult for users who remove unneeded packages). I get that things change, but it's sad to see people pushing Arch in that direction. Minimalism is one of Arch's defining features imo. If packagers do their job (provide package metadata), then pacman can do its job (dep resolution). It's really that simple. If you absolutely want a minimal common group with e.g. glibc, coreutils, linux and whatever else is effectively indispensable, then ok. Even then those packages should be resolved by pacman/makepkg. Regards, Xyne
Re: [aur-general] Should "base" packages be listed as dependencies?
Em março 29, 2017 4:32 Baptiste Jonglez escreveu: So, I didn't think such a technical question would spark so much passion! Maybe this discussion should indeed go to arch-dev-public. In the meantime, I see 4 positions emerge from the discussion: 1) packages in "base" *should* be explicitely listed as dependencies (either for mere "technical correctness", or because of bloat, i.e. not everyone wants/needs all packages from "base") This is the only valid option. 2) packages in "base" *should not* be listed as dependencies (because it is assumed that all Arch Linux systems have all packages from "base" already installed) Wrong. 3) it depends on the maintainer (i.e. there are no guidelines on this question) If you build using devtools, this become quite obvious. 4) it depends on the base package in question (e.g. it would be acceptable to depend on glibc, but not on systemd) Dependencies are dependencies. You can pull in a chain, by bringing the last link of it, so you don't have to list all of them. But you need to explicitly put everything you need for the program to build, test and run. Either this be on base, base-devel or on repos, core, extra, community. I get the impression that 3) is the current status quo. I find 4) to be quite strange and subjective, but it could be done (e.g. only allow library dependency such as glibc, or allow all dependencies except a few like systemd). I have seem packages on the repos that failed to build using a clean chroot[0]. I reported and they were fixed. I have two more arguments in favour of 1) or 4), related to technical correctness: - when a new version of glibc is released, which packages should be rebuilt? Without complete dependency information, I don't see how it's possible to know. There are tools for finding this. But this should really be on the package dependency list. Keep in mind that only packages that link directly to it need to be rebuilt (mostly). - Assume that all "base" packages are supposed to already be installed, and thus no other package depends on "base" packages. When a new package X is added to "base", how is an already-running system supposed to pick it up if no dependency pulls it in? base is an arbitrary set of packages, as this whole discussion showed us, in abundance. And it's not like pulling base will hurt you, but not everyone needs/wants to pull it in. Explicit dependency (chain considered) is the only way. [0] https://bugs.archlinux.org/task/51613 pgpNXaReRampG.pgp Description: PGP signature
Re: [aur-general] Should "base" packages be listed as dependencies?
On 29-03-17 09:32, Baptiste Jonglez wrote: So, I didn't think such a technical question would spark so much passion! Maybe this discussion should indeed go to arch-dev-public. In the meantime, I see 4 positions emerge from the discussion: 1) packages in "base" *should* be explicitely listed as dependencies (either for mere "technical correctness", or because of bloat, i.e. not everyone wants/needs all packages from "base") 2) packages in "base" *should not* be listed as dependencies (because it is assumed that all Arch Linux systems have all packages from "base" already installed) 3) it depends on the maintainer (i.e. there are no guidelines on this question) 4) it depends on the base package in question (e.g. it would be acceptable to depend on glibc, but not on systemd) I get the impression that 3) is the current status quo. I find 4) to be quite strange and subjective, but it could be done (e.g. only allow library dependency such as glibc, or allow all dependencies except a few like systemd). I have two more arguments in favour of 1) or 4), related to technical correctness: - when a new version of glibc is released, which packages should be rebuilt? Without complete dependency information, I don't see how it's possible to know. - Assume that all "base" packages are supposed to already be installed, and thus no other package depends on "base" packages. When a new package X is added to "base", how is an already-running system supposed to pick it up if no dependency pulls it in? Baptiste It looks like many here haven't looked at base group in a while, or don't distinguish between base group and core repository. example : systemd-sysvcompat is in base, systemd is NOT . Both are in core repo . LW
Re: [aur-general] Should "base" packages be listed as dependencies?
Le 29 mars 2017 00:32:09 GMT-07:00, Baptiste Jonglez a écrit : >So, I didn't think such a technical question would spark so much >passion! >Maybe this discussion should indeed go to arch-dev-public. Probably, since this is not just discussing the AUR policy but packaging at the whole scale. >In the meantime, I see 4 positions emerge from the discussion: > >1) packages in "base" *should* be explicitely listed as dependencies >(either for mere "technical correctness", or because of bloat, i.e. not > everyone wants/needs all packages from "base") That’s what I’m in favour of, but there is another option you’ve forgot about that could potentially suits me as well (see below). >2) packages in "base" *should not* be listed as dependencies (because >it > is assumed that all Arch Linux systems have all packages from "base" > already installed) Most of my installs consist of only few base packages installed as explicit, and probably half of base packages not being installed at all. I expect that to be a valid install, and I indeed don’t like bloat. >3) it depends on the maintainer (i.e. there are no guidelines on this >question) > >4) it depends on the base package in question (e.g. it would be >acceptable > to depend on glibc, but not on systemd) > > >I get the impression that 3) is the current status quo. I find 4) to >be >quite strange and subjective, but it could be done (e.g. only allow >library dependency such as glibc, or allow all dependencies except a >few >like systemd). > >I have two more arguments in favour of 1) or 4), related to technical >correctness: > >- when a new version of glibc is released, which packages should be >rebuilt? Without complete dependency information, I don't see how it's > possible to know. I think that TODO for rebuilding are determined by looking at ldd output, or at least they could. But I would not make that an argument for removing glibc from depends, it will anyway be indirectly depended on for most packages. >- Assume that all "base" packages are supposed to already be installed, > and thus no other package depends on "base" packages. When a new >package X is added to "base", how is an already-running system supposed > to pick it up if no dependency pulls it in? Which is a very good argument. Also, from the discussion there is 2.b) option, which consist in additionaly redefining base (and potentially base-devel as well, but let’s keep this separated) to really only consist of the minimal core system (maybe something in the like of pacman, glibc, systemd, linux, a shell, UNIX tools, and their dependencies). But maybe that definition of base would already be controversial/to subjective in which case we’re back to 1) being the only correct solution I would say. Bruno
Re: [aur-general] Should "base" packages be listed as dependencies?
So, I didn't think such a technical question would spark so much passion! Maybe this discussion should indeed go to arch-dev-public. In the meantime, I see 4 positions emerge from the discussion: 1) packages in "base" *should* be explicitely listed as dependencies (either for mere "technical correctness", or because of bloat, i.e. not everyone wants/needs all packages from "base") 2) packages in "base" *should not* be listed as dependencies (because it is assumed that all Arch Linux systems have all packages from "base" already installed) 3) it depends on the maintainer (i.e. there are no guidelines on this question) 4) it depends on the base package in question (e.g. it would be acceptable to depend on glibc, but not on systemd) I get the impression that 3) is the current status quo. I find 4) to be quite strange and subjective, but it could be done (e.g. only allow library dependency such as glibc, or allow all dependencies except a few like systemd). I have two more arguments in favour of 1) or 4), related to technical correctness: - when a new version of glibc is released, which packages should be rebuilt? Without complete dependency information, I don't see how it's possible to know. - Assume that all "base" packages are supposed to already be installed, and thus no other package depends on "base" packages. When a new package X is added to "base", how is an already-running system supposed to pick it up if no dependency pulls it in? Baptiste On Wed, Mar 22, 2017 at 09:45:13PM +0100, Baptiste Jonglez wrote: > Hi, > > I was pretty confident that "base" packages should be listed as > dependencies in PKGBUILDs, i.e. they are not assumed to be installed (as > opposed to "base-devel" for build dependencies). > > This belief is reinforced by the fact that namcap gives dependencies error > about packages such as glibc (which is in "base"): > > E: Dependency glibc detected and not included (libraries > ['usr/lib/libc.so.6', 'usr/lib/libcrypt.so.1'] needed in files > ['usr/lib/libcli.so.1.9.7']) > > But I could not find any documentation about this. On the contrary, this > wiki page [1] says the opposite: > > In addition, the base group is assumed to be installed on *all* Arch > systems. > > Am I missing something obvious? > > Thanks, > Baptiste > > [1] https://wiki.archlinux.org/index.php/Makepkg#Usage signature.asc Description: PGP signature
