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.
Loo
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 i
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
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
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 ho
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
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.
>
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 th
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, initsc
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 Wed, Jan 19, 2011 at 1:15 PM, Kaiting Chen wrote:
> On Wed, Jan 19, 2011 at 10:19 AM, Ray Rashif 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 u
On Wed, Jan 19, 2011 at 10:19 AM, Ray Rashif 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) responsib
On 19 January 2011 22:23, Stéphane Gaudreault 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 (an
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 depen
On Wed, Jan 19, 2011 at 14:46, Pierre Chapuis wrote:
> On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae 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 updat
On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae
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
On Wed, Jan 19, 2011 at 13:21, Allan McRae wrote:
> On 19/01/11 23:09, Magnus Therning wrote:
>>
>> On Wed, Jan 19, 2011 at 13:07, Allan McRae wrote:
>>>
>>> On 19/01/11 22:49, Magnus Therning wrote:
On Wed, Jan 19, 2011 at 12:50, Allan McRae
wrote:
>
> On 19/01/11 22:20,
Le 19 janvier 2011 09:07:33, Pierre Chapuis a écrit :
> On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae
>
> 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
On 20/01/11 00:07, Pierre Chapuis wrote:
On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae
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 clos
On Wed, Jan 19, 2011 at 2:07 PM, Pierre Chapuis wrote:
>
> 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
On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae
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 pack
On 19/01/11 23:49, Pierre Chapuis wrote:
On Wed, 19 Jan 2011 23:19:33 +1000, Allan McRae
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 r
On Wed, 19 Jan 2011 23:19:33 +1000, Allan McRae
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 b
Le 19 janvier 2011 08:36:04, Cédric Girard a écrit :
> On Wed, Jan 19, 2011 at 2:30 PM, Stéphane Gaudreault
>
> > 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 "read
On Wed, Jan 19, 2011 at 2:30 PM, Stéphane Gaudreault 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.
>
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 McRae 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 dependenc
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 d
On 19/01/11 23:09, Magnus Therning wrote:
On Wed, Jan 19, 2011 at 13:07, Allan McRae wrote:
On 19/01/11 22:49, Magnus Therning wrote:
On Wed, Jan 19, 2011 at 12:50, Allan McRaewrote:
On 19/01/11 22:20, Thomas Bächler wrote:
Am 19.01.2011 08:08, schrieb Allan McRae:
If we want to be
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 e
On Wed, Jan 19, 2011 at 13:07, Allan McRae wrote:
> On 19/01/11 22:49, Magnus Therning wrote:
>>
>> On Wed, Jan 19, 2011 at 12:50, Allan McRae 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 a
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 dependencie
On Wed, Jan 19, 2011 at 10:57 AM, Seblu 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
On 19/01/11 22:49, Magnus Therning wrote:
On Wed, Jan 19, 2011 at 12:50, Allan McRae 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
On Wed, Jan 19, 2011 at 1:39 PM, Thomas Bächler 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 shoul
On Wed, Jan 19, 2011 at 12:50, Allan McRae 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
>>> depen
On Wed, 19 Jan 2011 13:20:58 +0100
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 corr
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
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 depen
On Wed, Jan 19, 2011 at 1:20 PM, 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 thi
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
On Wed, 19 Jan 2011 17:08:27 +1000
Allan McRae 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
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 i
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 wh
43 matches
Mail list logo
