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
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, 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 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 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 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 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, 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 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 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
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 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
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 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
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
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
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: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, 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
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: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 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 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
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 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,
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 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 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 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
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]
On Tue, 18 Jan 2011 19:35:23 -0900 Lou 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)
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 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
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'
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!
On Wed, Jan 19, 2011 at 4:58 PM, Lukas Fleischer
wrote:
> 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
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
On Wed, Jan 19, 2011 at 6:04 PM, Gergely Imreh 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
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
On Wed, Jan 19, 2011 at 6:34 PM, Lou 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
40 matches
Mail list logo
