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
Cédric Girard wrote:
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.
I agree with this. A package should list as its dependencies any package on
which it
On 21/01/11 22:38, Xyne wrote:
If everyone were to use implicit dependencies then pacman would fail because no
package would specify the required dependency. A rule that would break the
system if it were followed by everyone is a bad rule. Expecting some to follow
it and others not to and just
Allan McRae wrote:
I pointed out that hard rules are not good. e.g. coreutils should (and
does) depend on glibc as it is not guaranteed that glibc is installed at
the time when you first install coreutils (which is likely the initial
install). But there is no point putting glibc in the
On 22/01/11 00:43, Xyne wrote:
Allan McRae wrote:
I pointed out that hard rules are not good. e.g. coreutils should (and
does) depend on glibc as it is not guaranteed that glibc is installed at
the time when you first install coreutils (which is likely the initial
install). But there is no
On 2011-01-22 01:29 +1000 (03:6)
Allan McRae wrote:
On 22/01/11 00:43, Xyne wrote:
Allan McRae wrote:
I pointed out that hard rules are not good. e.g. coreutils should (and
does) depend on glibc as it is not guaranteed that glibc is installed at
the time when you first install
On 22/01/11 01:57, Xyne wrote:
So if I wrote bindings to libalpm in Haskell (haskell-libalpm) and then created
a package with a binary that used those bindings (foo), then readelf's output
would not indicate libalpm?
Short answer is probably not... especially if you use -Wl,--as-needed.
On 2011-01-19 at 08:30:14 -0500, Stéphane Gaudreault wrote:
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
On Thu, 2011-01-20 at 11:29 +0100, Elena ``of Valhalla'' wrote:
On 2011-01-19 at 08:30:14 -0500, Stéphane Gaudreault wrote:
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,
As a reference, redhat/fedora have this same problem, the packages which
need not be included as deps are the packages used when creating the chroot
on the fedora build server, koji,
This list is very short, give me a minute and I will dig it up, but it is
only say 10 packages long.
Personally
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'
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
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
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
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
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
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
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
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
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
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,
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
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
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,
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
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
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
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
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,
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
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
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
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
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.
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
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
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
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
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
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
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
On Wed, 19 Jan 2011 00:19:50 -0500, 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
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
43 matches
Mail list logo
