Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae <allan@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
On Wed, Jan 19, 2011 at 14:46, Pierre Chapuis <catwell@archlinux.us> wrote:
On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae <allan@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: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
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
Allan McRae wrote:
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
I consider the correctness of metadata to be an advantage in itself. Relying on implicit rules is ugly and will inevitably cause problems. I've actually run into some of those, e.g. when installing pacman|makepkg in a chroot... it assumes several dependencies (e.g. "file"). There's a dusty bug-report about that on Flyspray. I've always though that even implicitly depending on base-devel is just lazy. It actually goes against the Arch way in that it expects users to dump several packages on their system that they may never use in order to satisfy dependencies that might arise... that's easily falls under the definition of "bloat", even if it doesn't require significant disk space by modern standards. How much overhead is there in checking all direct deps explicitly? Does adding a few pkgnames to the array really make a noticeable difference? I would expect that it takes considerably more time to track down groups and providers, given that metadata from the db has to be loaded for those, whereas resolving a dep will in most cases only require checking for an entry in the db (and resolving it further if it's not installed, but most operations are upgrade operations and those usually have their deps already satisfied). +1 for including it as an explicit dependency. Regards, Xyne
participants (4)
-
Allan McRae
-
Magnus Therning
-
Pierre Chapuis
-
Xyne