On Fri, 11 Dec 2009, Nagy Gabor wrote:
depends files are read in order to ensure that the upgraded package
won't break any old dependencies.
Example: local foo requires bar=2.0 (which is installed)
Then pacman -S bar is not allowed (if bar in sync has different
version).
I see now, thanks! So
Dimitrios Apostolou wrote:
On Fri, 11 Dec 2009, Nagy Gabor wrote:
depends files are read in order to ensure that the upgraded package
won't break any old dependencies.
Example: local foo requires bar=2.0 (which is installed)
Then pacman -S bar is not allowed (if bar in sync has different
On Fri, 11 Dec 2009, Nagy Gabor wrote:
depends files are read in order to ensure that the upgraded package
won't break any old dependencies.
Example: local foo requires bar=2.0 (which is installed)
Then pacman -S bar is not allowed (if bar in sync has different
version).
I just noticed that
Dimitrios Apostolou wrote:
On Fri, 11 Dec 2009, Nagy Gabor wrote:
depends files are read in order to ensure that the upgraded package
won't break any old dependencies.
Example: local foo requires bar=2.0 (which is installed)
Then pacman -S bar is not allowed (if bar in sync has different
On Sat, 12 Dec 2009, Allan McRae wrote:
Dimitrios Apostolou wrote:
On Fri, 11 Dec 2009, Nagy Gabor wrote:
depends files are read in order to ensure that the upgraded package
won't break any old dependencies.
Example: local foo requires bar=2.0 (which is installed)
Then pacman -S
On Fri, 11 Dec 2009, Nagy Gabor wrote:
depends files are read in order to ensure that the upgraded package
won't break any old dependencies.
Example: local foo requires bar=2.0 (which is installed)
Then pacman -S bar is not allowed (if bar in sync has different
version).
I just
Xavier wrote:
On Thu, Dec 3, 2009 at 10:43 AM, Allan McRae al...@archlinux.org wrote:
OK, your comment about the external commands being used having good error
messages has me convinced something needs done. It just seems a strange
place for this particular clean up. Saying that, I'm not sure
Sebastian Nowicki wrote:
As you may have heard, I started a proper PKGBUILD parser[1], which
parses according to shell semantics and does a little interpreting. I
just released the first version, which doesn't handle errors, or
multi-line values (like arrays or escaped newlines) very well. It
On Sat, Dec 12, 2009 at 3:11 PM, Allan McRae al...@archlinux.org wrote:
Sebastian Nowicki wrote:
As you may have heard, I started a proper PKGBUILD parser[1], which parses
according to shell semantics and does a little interpreting. I just released
the first version, which doesn't handle
Laszlo Papp wrote:
On Sat, Dec 12, 2009 at 3:11 PM, Allan McRae al...@archlinux.org wrote:
Sebastian Nowicki wrote:
As you may have heard, I started a proper PKGBUILD parser[1], which parses
according to shell semantics and does a little interpreting. I just released
the first version, which
---
src/pacman/util.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c
index 115b367..e23d96d 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -446,8 +446,11 @@ void list_display(const char *title, const
On Sat, Dec 12, 2009 at 3:36 PM, Laszlo Papp djsz...@archlinux.us wrote:
On Sat, Dec 12, 2009 at 3:11 PM, Allan McRae al...@archlinux.org wrote:
Sebastian Nowicki wrote:
As you may have heard, I started a proper PKGBUILD parser[1], which parses
according to shell semantics and does a little
Xavier wrote:
I can't help but think this whole situation is stupid.
I would suppose that PKGBUILDs were written in bash for simplicity
reason : makepkg just needs to source them, and that's it. Whole
parsing done for free.
And now we realize that when using untrusted source, we cannot do that
On Sat, Dec 12, 2009 at 5:46 AM, Allan McRae al...@archlinux.org wrote:
Dimitrios Apostolou wrote:
On Fri, 11 Dec 2009, Nagy Gabor wrote:
depends files are read in order to ensure that the upgraded package
won't break any old dependencies.
Example: local foo requires bar=2.0 (which is
On Sat, 12 Dec 2009, Dimitrios Apostolou wrote:
P.S. Is there some option --pretend I might have missed? What I need is to
get exactly the same actions of pacman -S blah or pacman -Su until the
Y/N prompt, as non-root user.
Regarding this issue, it's the first I tried to fix since I didn't
On Sat, 12 Dec 2009, Dimitrios Apostolou wrote:
P.S. Is there some option --pretend I might have missed? What I
need is to get exactly the same actions of pacman -S blah or
pacman -Su until the Y/N prompt, as non-root user.
Regarding this issue, it's the first I tried to fix since I
On Sat, 12 Dec 2009, Dimitrios Apostolou wrote:
Hello list,
I have been investigating the slow performance of pacman regarding the cold
caches scenario and I'm trying to write some proof of concept code that
improves things a lot for some cases. However I need your help regarding some
facts
On Sat, 12 Dec 2009, Dimitrios Apostolou wrote:
Hello list,
I have been investigating the slow performance of pacman regarding
the cold caches scenario and I'm trying to write some proof of
concept code that improves things a lot for some cases. However I
need your help regarding some
On Sat, 12 Dec 2009, Nagy Gabor wrote:
On Sat, 12 Dec 2009, Dimitrios Apostolou wrote:
Regarding the stat() and access() operations I finally found out why
they happen exactly:
In case of corrupted db the sync, for example, directory might
contain files, not subdirectories. So in that case
Dan McGee wrote:
I think most of this thread is the wrong approach to the problem.
Rather than try to meld the DB to fit pacman, we should just swap out
DBs so it doesn't have these bad worst-case conditions.
$ du -sh --apparent-size local/ sync/*
15M local/
8.4Msync/community
31K
On Sat, Dec 12, 2009 at 5:30 PM, Allan McRae al...@archlinux.org wrote:
Xavier wrote:
I can't help but think this whole situation is stupid.
I would suppose that PKGBUILDs were written in bash for simplicity
reason : makepkg just needs to source them, and that's it. Whole
parsing done for
21 matches
Mail list logo
