Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, 19 Jan 2011 17:08:27 +1000 Allan McRae al...@archlinux.org wrote: On 19/01/11 15:19, Kaiting Chen wrote: Okay everyone, every time I ask I get a different answer. According to Dziedzic and Allan 'glibc' does *not* belong in 'depends'. Also Dziedzic votes that *no* package in 'base' should be in 'depends'. Can we settle once and for all what the correct policy is? And then can we update the wiki page and all of these packages http://www.archlinux.org/packages/core/i686/glibc/so that they reflect the policy? --Kaiting. In general, I think packages in 'base' need listed. Mainly because I do not install a fair number of the base packages and would have even less of them installed if they were not listed as dependencies. If we allow users to not (explicitly) install base packages and support such schemes by adding more detailed dependencies, then we could just as well scratch the base group, because it becomes pointless. Actually I would prefer this approach: throw the concept of the base group away, all the *needed* packages will get installed anyway, because they are dependencies for packages the user explictly wants. Dieter
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 1:20 PM, Thomas Bächler tho...@archlinux.org wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: +1 If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. And this check is done by a software not by a scientist predicate that varies depending on the experience of maintainer. -- Sébastien Luttringer www.seblu.net
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Am 19.01.2011 13:32, schrieb Seblu: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. And this check is done by a software not by a scientist predicate that varies depending on the experience of maintainer. For library-dependencies on binaries, yes. On scripts it is much harder to check this. I don't think it is possible to cover all cases with a piece of software here, but one should try. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On 19/01/11 22:20, Thomas Bächler wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I agree that would be the correct thing to do. In fact, I looked at doing this to the extent of including ever package that a program linked to in its dependencies. This increases the number of dependencies needed for the average package in the repos greatly (from memory it averaged a several fold increase). The side effect of that is there is obviously a correspondingly big increase in the number of dependency checks that pacman needs to do for each update and the associated speed hit. I always assumed that we did not list all dependencies for speed reasons. Allan
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, 19 Jan 2011 13:20:58 +0100 Thomas Bächler tho...@archlinux.org wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I'm also fan of this. The added correctness (both informational and system robustness) justifies the little overhead, imho. Dieter
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 12:50, Allan McRae al...@archlinux.org wrote: On 19/01/11 22:20, Thomas Bächler wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I agree that would be the correct thing to do. In fact, I looked at doing this to the extent of including ever package that a program linked to in its dependencies. This increases the number of dependencies needed for the average package in the repos greatly (from memory it averaged a several fold increase). I don't quite understand what you mean, did you add the transitive closure of all dependencies to the package, or did you only add all direct dependencies? The side effect of that is there is obviously a correspondingly big increase in the number of dependency checks that pacman needs to do for each update and the associated speed hit. I always assumed that we did not list all dependencies for speed reasons. Well, if the creation of the transitive closure of dependencies is created at package build time, then it can be removed from pacman, that should give a bit of a speed-up I suspect. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 1:39 PM, Thomas Bächler tho...@archlinux.org wrote: Am 19.01.2011 13:32, schrieb Seblu: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. And this check is done by a software not by a scientist predicate that varies depending on the experience of maintainer. For library-dependencies on binaries, yes. On scripts it is much harder to check this. I don't think it is possible to cover all cases with a piece of software here, but one should try. I was not clear. I just wanted to support your example and suggest to Allan that it will be better that Pacman do this job, even if, cost is important. IMHO, it's better than pacman take some seconds more to check complex dependency, rather than maintenairs do it manually, based on their time based knownledge of depencies. Pacman is also less subject to human error. With our modern computer, I do not see why the calculation of the dependency graph take more than few seconds -- Sébastien Luttringer www.seblu.net
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On 19/01/11 22:49, Magnus Therning wrote: On Wed, Jan 19, 2011 at 12:50, Allan McRaeal...@archlinux.org wrote: On 19/01/11 22:20, Thomas Bächler wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I agree that would be the correct thing to do. In fact, I looked at doing this to the extent of including ever package that a program linked to in its dependencies. This increases the number of dependencies needed for the average package in the repos greatly (from memory it averaged a several fold increase). I don't quite understand what you mean, did you add the transitive closure of all dependencies to the package, or did you only add all direct dependencies? Essentially readelf -d on the files and add all needed packages to the dependencies. I.e. list all packages that are directly linked. Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? Allan
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 10:57 AM, Seblu se...@seblu.net wrote: I just wanted to support your example and suggest to Allan that it will be better that Pacman do this job, even if, cost is important. IMHO, it's better than pacman take some seconds more to check complex dependency, rather than maintenairs do it manually, based on their time based knownledge of depencies. Pacman is also less subject to human error. I think you misunderstood the problem. Pacman already does that (calculate the graph of dependencies) when installing packages. The problem discussed here is the way of informing pacman about that dependencies. The original question was if it is necessary to specify packages of the base group in the depends array of a PKGBUILD. And that is a harder problem to solve, because the packages must know very well the program being packaged, so he decides what is a direct dependency and what is not. There are tools to help with binaries and libraries, but not for non-linkable dependencies (scripts or tools for processing, for example). -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto Linux user #524555 ---
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Am 19.01.2011 14:07, schrieb Allan McRae: Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? It's the exact opposite. You list all dependencies, and dependencies of dependencies, and ... signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 13:07, Allan McRae al...@archlinux.org wrote: On 19/01/11 22:49, Magnus Therning wrote: On Wed, Jan 19, 2011 at 12:50, Allan McRaeal...@archlinux.org wrote: On 19/01/11 22:20, Thomas Bächler wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I agree that would be the correct thing to do. In fact, I looked at doing this to the extent of including ever package that a program linked to in its dependencies. This increases the number of dependencies needed for the average package in the repos greatly (from memory it averaged a several fold increase). I don't quite understand what you mean, did you add the transitive closure of all dependencies to the package, or did you only add all direct dependencies? Essentially readelf -d on the files and add all needed packages to the dependencies. I.e. list all packages that are directly linked. Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? Nope, it's the opposite: • A depends on B • B depends on C If the PKGBUILD for A lists the transitive closure, then it would have depends=(B C) As we do now the transitive closure is calculated by pacman in order to make sure all dependencies are installed. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On 19/01/11 23:07, Thomas Bächler wrote: Am 19.01.2011 14:07, schrieb Allan McRae: Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? It's the exact opposite. You list all dependencies, and dependencies of dependencies, and ... Ah... OK. then I don't understand this: On 19/01/11 22:49, Magnus Therning wrote: Well, if the creation of the transitive closure of dependencies is created at package build time, then it can be removed from pacman, that should give a bit of a speed-up I suspect. When pacman does dependency checks, it checks if the package listed in the dependencies is installed. It does not check if all its dependencies are installed too (as it is assumed that was done at the time the dependency was installed). If we list the transitive closure of dependencies, then pacman has to perform extra checks and so will not give a speed-up. Allan
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On 19/01/11 23:09, Magnus Therning wrote: On Wed, Jan 19, 2011 at 13:07, Allan McRaeal...@archlinux.org wrote: On 19/01/11 22:49, Magnus Therning wrote: On Wed, Jan 19, 2011 at 12:50, Allan McRaeal...@archlinux.orgwrote: On 19/01/11 22:20, Thomas Bächler wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I agree that would be the correct thing to do. In fact, I looked at doing this to the extent of including ever package that a program linked to in its dependencies. This increases the number of dependencies needed for the average package in the repos greatly (from memory it averaged a several fold increase). I don't quite understand what you mean, did you add the transitive closure of all dependencies to the package, or did you only add all direct dependencies? Essentially readelf -d on the files and add all needed packages to the dependencies. I.e. list all packages that are directly linked. Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? Nope, it's the opposite: • A depends on B • B depends on C If the PKGBUILD for A lists the transitive closure, then it would have depends=(B C) As we do now the transitive closure is calculated by pacman in order to make sure all dependencies are installed. Nope. We currently list depends=(B) and pacman just checks B is installed. Allan
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Am 19.01.2011 14:19, schrieb Allan McRae: On 19/01/11 23:07, Thomas Bächler wrote: It's the exact opposite. You list all dependencies, and dependencies of dependencies, and ... Ah... OK. then I don't understand this: Don't worry, me neither. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Le 19 janvier 2011 08:07:00, Allan McRae a écrit : On 19/01/11 22:49, Magnus Therning wrote: On Wed, Jan 19, 2011 at 12:50, Allan McRaeal...@archlinux.org wrote: On 19/01/11 22:20, Thomas Bächler wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I agree that would be the correct thing to do. In fact, I looked at doing this to the extent of including ever package that a program linked to in its dependencies. This increases the number of dependencies needed for the average package in the repos greatly (from memory it averaged a several fold increase). I don't quite understand what you mean, did you add the transitive closure of all dependencies to the package, or did you only add all direct dependencies? Essentially readelf -d on the files and add all needed packages to the dependencies. I.e. list all packages that are directly linked. Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? Allan I think Allan is right here. If we look at the problem from another angle, thing are very simple : 1) There is a groupe of packages that are required. Theses packages are necessary for the proper functioning of the system (eg. a kernel, a boot loader, initscript, glibc, etc). The system will not run well or be usable without will be here. It is not necessary for other package to depends on them, because they **should** be there (although it does not hurt if a package depends on them). 2) Starting from this base, package A depends on Package B if B absolutely must be installed in order to run A. In some cases, A depends not only on B, but on a version of B. In this case, the version dependency is usually a lower limit, in the sense that A depends on any version of B more recent than some specified version. This gives a simple receipie : When you want to list the dependency fo a package, simply look at what is directly used (for binary it is essentially readelf -d on the files) and you get the dependency list for your package. You can then assume that everything will be correct as maintainers of the listed packages did the same up to the required group. If there is something missing in the dependencies of your dependencies send a bug report. Stéphane
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 2:30 PM, Stéphane Gaudreault steph...@archlinux.org wrote: This gives a simple receipie : When you want to list the dependency fo a package, simply look at what is directly used (for binary it is essentially readelf -d on the files) and you get the dependency list for your package. You can then assume that everything will be correct as maintainers of the listed packages did the same up to the required group. It means then that if we have this (dependency are direct dependencies): - Package A: depends=(B C) - Package B: depends=(C) C should *not* be removed from the dependency array of A. -- Cédric Girard
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Le 19 janvier 2011 08:36:04, Cédric Girard a écrit : On Wed, Jan 19, 2011 at 2:30 PM, Stéphane Gaudreault steph...@archlinux.org wrote: This gives a simple receipie : When you want to list the dependency fo a package, simply look at what is directly used (for binary it is essentially readelf -d on the files) and you get the dependency list for your package. You can then assume that everything will be correct as maintainers of the listed packages did the same up to the required group. It means then that if we have this (dependency are direct dependencies): - Package A: depends=(B C) - Package B: depends=(C) C should *not* be removed from the dependency array of A. Exact, you list what you directly use. It also means that if we have this (dependency are direct dependencies): - Package A: depends=(B C) - Package B: depends=(D) Maintainer of package A should not worry about dependency of B unless something is broken. Then simply fill a bug report. Stéphane
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, 19 Jan 2011 23:19:33 +1000, Allan McRae al...@archlinux.org wrote: Ah... OK. then I don't understand this: On 19/01/11 22:49, Magnus Therning wrote: Well, if the creation of the transitive closure of dependencies is created at package build time, then it can be removed from pacman, that should give a bit of a speed-up I suspect. When pacman does dependency checks, it checks if the package listed in the dependencies is installed. It does not check if all its dependencies are installed too (as it is assumed that was done at the time the dependency was installed). If we list the transitive closure of dependencies, then pacman has to perform extra checks and so will not give a speed-up. Well, except if you assume that all packages do this perfectly. Then when installing a package with '-S' Pacman can install its dependencies with the equivalent of '-Sd', which will be faster. I find that approach dangerous though... -- Pierre 'catwell' Chapuis
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On 19/01/11 23:49, Pierre Chapuis wrote: On Wed, 19 Jan 2011 23:19:33 +1000, Allan McRae al...@archlinux.org wrote: Ah... OK. then I don't understand this: On 19/01/11 22:49, Magnus Therning wrote: Well, if the creation of the transitive closure of dependencies is created at package build time, then it can be removed from pacman, that should give a bit of a speed-up I suspect. When pacman does dependency checks, it checks if the package listed in the dependencies is installed. It does not check if all its dependencies are installed too (as it is assumed that was done at the time the dependency was installed). If we list the transitive closure of dependencies, then pacman has to perform extra checks and so will not give a speed-up. Well, except if you assume that all packages do this perfectly. Then when installing a package with '-S' Pacman can install its dependencies with the equivalent of '-Sd', which will be faster. Huh? How is no dependency checks (-Sd) equivalent to complete dependency checking (-S with a transitive closure of dependencies)? They are polar opposites. Allan
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae al...@archlinux.org wrote: Huh? How is no dependency checks (-Sd) equivalent to complete dependency checking (-S with a transitive closure of dependencies)? They are polar opposites. What I mean is that if a transitive closure of dependencies is performed at packaging time, then there is no need to check for dependencies when installing the original package. Here is an example: A depends on B and D B depends on C C depends on D and E Currently the deps will be: A - B,D B - C C - D,E When installing A, Pacman will: 1) check deps for A, start installing B and D 2) check deps for B and D, start installing C 3) check deps for C, start installing E With a transitive closure scheme at packaging time, the deps would be: A - B,C,D,E B - C,D,E C - D,E When installing A, Pacman could simply install B, C, D and E *without* checking their deps (-Sd) because these deps are necessarily already included in those for A. -- Pierre 'catwell' Chapuis
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 2:07 PM, Pierre Chapuis catw...@archlinux.uswrote: Here is an example: A depends on B and D B depends on C C depends on D and E Currently the deps will be: A - B,D B - C C - D,E When installing A, Pacman will: 1) check deps for A, start installing B and D 2) check deps for B and D, start installing C 3) check deps for C, start installing E With a transitive closure scheme at packaging time, the deps would be: A - B,C,D,E B - C,D,E C - D,E When installing A, Pacman could simply install B, C, D and E *without* checking their deps (-Sd) because these deps are necessarily already included in those for A. -- Pierre 'catwell' Chapuis If B and D are already installed, the current implementation does 2 dependency checks and trasitive closure makes 4. Also, does not pacman need to know that C, D and E must be installed before B? Your approach would probably install B before its dependencies.
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On 20/01/11 00:07, Pierre Chapuis wrote: On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae al...@archlinux.org wrote: Huh? How is no dependency checks (-Sd) equivalent to complete dependency checking (-S with a transitive closure of dependencies)? They are polar opposites. What I mean is that if a transitive closure of dependencies is performed at packaging time, then there is no need to check for dependencies when installing the original package. Here is an example: A depends on B and D B depends on C C depends on D and E Currently the deps will be: A - B,D B - C C - D,E When installing A, Pacman will: 1) check deps for A, start installing B and D 2) check deps for B and D, start installing C 3) check deps for C, start installing E With a transitive closure scheme at packaging time, the deps would be: A - B,C,D,E B - C,D,E C - D,E When installing A, Pacman could simply install B, C, D and E *without* checking their deps (-Sd) because these deps are necessarily already included in those for A. The problem is that the transitive closure can not be assumed to be correct. e.g. At the time A is built: A - B,C,D,E B - C,D,E C - D,E Then B is updated and B - C,D,E,F. Now the assuming a transitive closure for the dependency list for A is incorrect. Installing the listed dependencies of A with the equivalent of -Sd would result in F not being installed which would break A through broken B. So either: 1) we require a largely unnecessary rebuild of A 2) we always check the dependencies of uninstalled dependencies. Note #2 is less burden on packagers and is more efficient in the examples given above if both B and D are installed (two checks vs four), and that will be the case for most system updates. When none of A - E are installed, they are probably equally efficient. Allan
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
Le 19 janvier 2011 09:07:33, Pierre Chapuis a écrit : On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae al...@archlinux.org wrote: Huh? How is no dependency checks (-Sd) equivalent to complete dependency checking (-S with a transitive closure of dependencies)? They are polar opposites. What I mean is that if a transitive closure of dependencies is performed at packaging time, then there is no need to check for dependencies when installing the original package. Here is an example: A depends on B and D B depends on C C depends on D and E Currently the deps will be: A - B,D B - C C - D,E When installing A, Pacman will: 1) check deps for A, start installing B and D 2) check deps for B and D, start installing C 3) check deps for C, start installing E With a transitive closure scheme at packaging time, the deps would be: A - B,C,D,E B - C,D,E C - D,E When installing A, Pacman could simply install B, C, D and E *without* checking their deps (-Sd) because these deps are necessarily already included in those for A. As the maintainer of A, it is not your job to track dependencies of B and D. Again, look at the problem from a different point of view. If tomorrow dependencies of B change to B - C F (direct dependecies) does it mean that A (and **all** other pkgs that depends on B) should be updated to include a dependecy on F ? What if dependency on E is removed from C PKGBUILD ? Maintaining a package with such rules will be a nightmare. Stéphane
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 13:21, Allan McRae al...@archlinux.org wrote: On 19/01/11 23:09, Magnus Therning wrote: On Wed, Jan 19, 2011 at 13:07, Allan McRaeal...@archlinux.org wrote: On 19/01/11 22:49, Magnus Therning wrote: On Wed, Jan 19, 2011 at 12:50, Allan McRaeal...@archlinux.org wrote: On 19/01/11 22:20, Thomas Bächler wrote: Am 19.01.2011 08:08, schrieb Allan McRae: If we want to be really pedantic about dependencies, we should list _ALL_ dependencies and not remove the ones that are dependencies of dependencies. Why don't we just do the correct thing: If package A depends on package B, and B depends on C, then A might depend on C explicitly because it accesses C directly. Or it might only depend on indirectly C because B accesses C. We should reflect that in dependencies (in the first case, A depends on C, in the second case it doesn't). The result is this: Whenever the dependencies of B change (e.g., C is removed), A will still work correctly. I agree that would be the correct thing to do. In fact, I looked at doing this to the extent of including ever package that a program linked to in its dependencies. This increases the number of dependencies needed for the average package in the repos greatly (from memory it averaged a several fold increase). I don't quite understand what you mean, did you add the transitive closure of all dependencies to the package, or did you only add all direct dependencies? Essentially readelf -d on the files and add all needed packages to the dependencies. I.e. list all packages that are directly linked. Its has been many years since I did graph theory... but isn't a transitive closure essentially what we have been doing with only listing the top level of dependencies and having them cover the rest? Nope, it's the opposite: • A depends on B • B depends on C If the PKGBUILD for A lists the transitive closure, then it would have depends=(B C) As we do now the transitive closure is calculated by pacman in order to make sure all dependencies are installed. Nope. We currently list depends=(B) and pacman just checks B is installed. All right, I need to clarify. If B *isn't* installed, then pacman will install both B *and* C; and there's the transitive closure. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae al...@archlinux.org wrote: The problem is that the transitive closure can not be assumed to be correct. e.g. At the time A is built: A - B,C,D,E B - C,D,E C - D,E Then B is updated and B - C,D,E,F. Now the assuming a transitive closure for the dependency list for A is incorrect. Installing the listed dependencies of A with the equivalent of -Sd would result in F not being installed which would break A through broken B. So either: 1) we require a largely unnecessary rebuild of A 2) we always check the dependencies of uninstalled dependencies. Note #2 is less burden on packagers and is more efficient in the examples given above if both B and D are installed (two checks vs four), and that will be the case for most system updates. When none of A - E are installed, they are probably equally efficient. Yes, I agree with that: dependencies will always have to be checked at package install time. That means that any approach based on a transitive closure at packaging time is useless. What could also happen is that C is updated and no longer needs E. Then, with a transitive closure, A would still install E, which would be useless for the user. So the only way to be safe is not to be clever and to specify real dependencies, eg: Real deps - A - B,D B - C C - D,E Transitive closure -- A - B,C,D,E B - C,D,E C - D,E Current Arch way A - B B - C C - D,E What should be done --- A - B,D B - C C - D,E -- Pierre 'catwell' Chapuis
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 14:46, Pierre Chapuis catw...@archlinux.us wrote: On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae al...@archlinux.org wrote: The problem is that the transitive closure can not be assumed to be correct. e.g. At the time A is built: A - B,C,D,E B - C,D,E C - D,E Then B is updated and B - C,D,E,F. Now the assuming a transitive closure for the dependency list for A is incorrect. Installing the listed dependencies of A with the equivalent of -Sd would result in F not being installed which would break A through broken B. So either: 1) we require a largely unnecessary rebuild of A 2) we always check the dependencies of uninstalled dependencies. Note #2 is less burden on packagers and is more efficient in the examples given above if both B and D are installed (two checks vs four), and that will be the case for most system updates. When none of A - E are installed, they are probably equally efficient. Yes, I agree with that: dependencies will always have to be checked at package install time. That means that any approach based on a transitive closure at packaging time is useless. What could also happen is that C is updated and no longer needs E. Then, with a transitive closure, A would still install E, which would be useless for the user. So the only way to be safe is not to be clever and to specify real dependencies, eg: Real deps - A - B,D B - C C - D,E Transitive closure -- A - B,C,D,E B - C,D,E C - D,E Current Arch way A - B B - C C - D,E What should be done --- A - B,D B - C C - D,E I think you are right, that's what should be done. I would argue though that the current Arch way actually is somewhere in between what you call Real deps and Current Arch way, simply because some package maintainers know what the real dependencies are and will put them in. Other package maintainers try to build in a chroot until it succeeds, and hence up at Current Arch way. In any case, this whole argument is rather besides the point :-) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On 20/01/11 00:46, Pierre Chapuis wrote: Real deps - A - B,D B - C C - D,E Current Arch way A - B B - C C - D,E I think we have established the Transitive closure is impractical, so lets exclude that. The current Arch way has the advantage of speed in dependency resolution if B is installed, but suffers from potential breakage if C removes D from its dependency list. How common would such breakage be? I'd argue that it would be fairly rare as software tends to gather more dependencies and not less. Also, since spreading the word about building in chroots, bug reports about missing dependencies are much rarer, again indicating it is not a common occurrance. Given we are competent Linux users around here and can deal with what would be minor breakage, I'd lean towards taking the speed advantage and fix the rare bugs as they occur. So getting back to the original point of this thread... if D is glibc, for most packages there is zero chance of breakage by not listing it as a dep of A because it will be on all systems. So there is only advantages! Of course, some low level packages in [core] rely on having glibc installed before them for correct system installation and so glibc should be listed in their depends list. So no rule about the inclusion or not of glibc in the depends list can really be made... it is up to the packager to know what they are packaging and make their own decisions. So my conclusion is to only list glibc as a dependency if you are packaging low level stuff that will be installed during the initial installation of a system. Otherwise, leave it out. Allan
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On 19 January 2011 22:23, Stéphane Gaudreault steph...@archlinux.org wrote: As the maintainer of A, it is not your job to track dependencies of B and D. Again, look at the problem from a different point of view. If tomorrow dependencies of B change to B - C F (direct dependecies) does it mean that A (and **all** other pkgs that depends on B) should be updated to include a dependecy on F ? What if dependency on E is removed from C PKGBUILD ? Maintaining a package with such rules will be a nightmare. If A depends on B AND C while B depends on C, then it is correct to list both B and C as dependencies of A. That is as proper as it gets, and this most of us do not practise currently. Aside from any technical disadvantage, it is just clutter to my eyes. It is also correct to list only B as a dependency of A, since B would pull in C, but this correctness is only assumed correctness, provided link-level dependency has not been checked. This, most of us do currently. PKGBUILDs and pacman dependency lists are easy to look at. I don't see a need to 'settle' this one. You may not list glibc because it simply makes no sense to not have it at the time of installation. It can be as far deep down as F, but ultimately it is the packagers' (and community's) responsibility to incorporate dependency changes. As a community, changes like this are hard to miss. C getting out of B's dependency chain does not happen a lot. When it does, someone can report it. So we (should) stick to the simple(r) way - the current way.
[aur-general] Warning: PyQt change
Hi AUR maintainers, I did a change in the pyqt package to add Python 3 support to it and to allow everyone to install both the Python2 and the Python3 version. Every package now need to depends on python2-qt (or python-qt if uses Python 3) instead of pyqt. The packages in [extra] and [community] have been updated, please do the same with your packages in AUR. Also, the packages which depend on sip have to be fixed with the right dependence: python2-sip (or python-sip if the package uses Python 3). Thank you! -- Andrea
Re: [aur-general] Request removal: emoc, myencoder, hypervideoconverter
On Tue, 18 Jan 2011 19:35:23 -0900 Lou l...@fakeoutdoorsman.com wrote: These are all old and orphaned packages that are encoding GUIs to ffmpeg. emoc http://aur.archlinux.org/packages.php?ID=34109 Doesn't work. Just sits there and does not actually convert any videos. Done. (orphan, last update 20100203) myencoder http://aur.archlinux.org/packages.php?ID=31640 Source does not pass the validity check. Upstream states, MyEncoding development has been scaled back on 2010-06-20. Done. (orphan, upstream shut down) hypervideoconverter http://aur.archlinux.org/packages.php?ID=21735 Flagged out of date. Upstream not updated since 2008-11-17 and its settings appear not to be compatible with ffmpeg in repository. Done. (orphan, last update 20081226) Thank you. -- Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 signature.asc Description: PGP signature
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 10:19 AM, Ray Rashif sc...@archlinux.org wrote: I don't see a need to 'settle' this one. You may not list glibc because it simply makes no sense to not have it at the time of installation. It can be as far deep down as F, but ultimately it is the packagers' (and community's) responsibility to incorporate dependency changes. As a community, changes like this are hard to miss. C getting out of B's dependency chain does not happen a lot. When it does, someone can report it. So we (should) stick to the simple(r) way - the current way. Um the current way is that everyone disagrees about what to do and then just does whatever they feel like doing. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Wed, Jan 19, 2011 at 1:15 PM, Kaiting Chen kaitocr...@gmail.com wrote: On Wed, Jan 19, 2011 at 10:19 AM, Ray Rashif sc...@archlinux.org wrote: I don't see a need to 'settle' this one. You may not list glibc because it simply makes no sense to not have it at the time of installation. It can be as far deep down as F, but ultimately it is the packagers' (and community's) responsibility to incorporate dependency changes. As a community, changes like this are hard to miss. C getting out of B's dependency chain does not happen a lot. When it does, someone can report it. So we (should) stick to the simple(r) way - the current way. Um the current way is that everyone disagrees about what to do and then just does whatever they feel like doing. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/ In my opinion, we need to create another group called 'base-core' which will be guaranteed to be installed like base-devel is guaranteed to be installed when making a package. I think this should be the way to go because a lot of packages in base aren't really needed in a minimal system.
[aur-general] delete request
please delete http://aur.archlinux.org/packages.php?ID=22403 as I am not developing it, and it is redundant to pkgfile. thanks, Jonathan wide-eye'
Re: [aur-general] delete request
On Wed, Jan 19, 2011 at 05:53:51PM -0500, jonathan wrote: please delete http://aur.archlinux.org/packages.php?ID=22403 as I am not developing it, and it is redundant to pkgfile. Done, thanks!
Re: [aur-general] delete request
On Wed, Jan 19, 2011 at 4:58 PM, Lukas Fleischer archli...@cryptocrack.dewrote: On Wed, Jan 19, 2011 at 05:53:51PM -0500, jonathan wrote: please delete http://aur.archlinux.org/packages.php?ID=22403 as I am not developing it, and it is redundant to pkgfile. Done, thanks! It'd be nice to know exactly what package is being deleted... Good thing Google's cache exists. Package is avalon.
[aur-general] delete request
Please delete python3-pyke http://aur.archlinux.org/packages.php?ID=45332 I uploaded a new package, python-pyke to follow the name convention of Arch for Python packages. Cheers, Greg
Re: [aur-general] delete request
On Wed, Jan 19, 2011 at 6:04 PM, Gergely Imreh imr...@gmail.com wrote: Please delete python3-pyke http://aur.archlinux.org/packages.php?ID=45332 I uploaded a new package, python-pyke to follow the name convention of Arch for Python packages. Cheers, Greg Deleted, thanks for the update Greg! -Tom Hatch
[aur-general] Request removal: ffmpeg-vp8-svn, servicemenu-kvm-kde4, winff-corrected
ffmpeg-vp8-svn http://aur.archlinux.org/packages.php?ID=37297 Orphan. Does not compile. FFmpeg in extra now has libvpx encoder making this package useless. servicemenu-kvm-kde4 http://aur.archlinux.org/packages.php?ID=36180 Orphan. Uses depreciated options that will not work with ffmpeg from extra. Upstream has been inactive for nearly 2 years. winff-corrected http://aur.archlinux.org/packages.php?ID=31348 Source is 404. Maintainer said, do whatever you want. I do not use Linux anymore.
Re: [aur-general] Request removal: ffmpeg-vp8-svn, servicemenu-kvm-kde4, winff-corrected
On Wed, Jan 19, 2011 at 6:34 PM, Lou l...@fakeoutdoorsman.com wrote: ffmpeg-vp8-svn http://aur.archlinux.org/packages.php?ID=37297 Orphan. Does not compile. FFmpeg in extra now has libvpx encoder making this package useless. servicemenu-kvm-kde4 http://aur.archlinux.org/packages.php?ID=36180 Orphan. Uses depreciated options that will not work with ffmpeg from extra. Upstream has been inactive for nearly 2 years. winff-corrected http://aur.archlinux.org/packages.php?ID=31348 Source is 404. Maintainer said, do whatever you want. I do not use Linux anymore. Thanks for finding these! they have been destroyed. -Tom Hatch
