FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 07-19-2008, 12:37 PM
Xavier
 
Default Fileconflict error...

Nagy Gabor wrote:
> Hi!
>
> I've tried -Su again...
> I've just run into a very "hard to fix" error.
>
> [ngaba@Arch ~]$ LANG=C sudo pacman -Su --ignore mplayer
> ...
> xulrunner: /usr/include/xulrunner-1.9 exists in filesystem
> xulrunner: /usr/lib/xulrunner-1.9 exists in filesystem
> xulrunner: /usr/lib/xulrunner-devel-1.9 exists in filesystem
> xulrunner: /usr/share/idl/xulrunner-1.9 exists in filesystem
> ...
>
> These are directories... But in the package we have symlinks.
>

I ran into this problem 10 seconds before receiving your mail :P

Anyway, if we removed xulrunner-1.9 before installing xulrunner-1.9.0.1,
this error shouldn't happen, because the files in these directories
apparently all belong to xulrunner.
Otherwise pacman could check for this propriety.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-19-2008, 01:55 PM
Nagy Gabor
 
Default Fileconflict error...

>
> I ran into this problem 10 seconds before receiving your mail :P
>
> Anyway, if we removed xulrunner-1.9 before installing
> xulrunner-1.9.0.1, this error shouldn't happen, because the files in
> these directories apparently all belong to xulrunner.
> Otherwise pacman could check for this propriety.
>

Yes. We should do ~query_fileowner() for all files in that dir
(and recurse to subdirs). For efficiency we should start with oldpkg,
because query_fileowner is not a fast operation (but the situation of
this thread is not common, so the speed is not so important here).
But this is not so trivial, we could consider NoUpgrade, ".pacsave"
stuffs too (and I may miss something here), if we want to _simulate_ our
transaction perfectly.

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-22-2008, 08:55 AM
Xavier
 
Default Fileconflict error...

On Sat, Jul 19, 2008 at 2:25 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
> Hi!
>
> I've tried -Su again...
> I've just run into a very "hard to fix" error.
>
> [ngaba@Arch ~]$ LANG=C sudo pacman -Su --ignore mplayer
> ...
> xulrunner: /usr/include/xulrunner-1.9 exists in filesystem
> xulrunner: /usr/lib/xulrunner-1.9 exists in filesystem
> xulrunner: /usr/lib/xulrunner-devel-1.9 exists in filesystem
> xulrunner: /usr/share/idl/xulrunner-1.9 exists in filesystem
> ...
>
> These are directories... But in the package we have symlinks.
>

I thought this was a regression caused by this fix :
http://bugs.archlinux.org/task/8156

But apparently this fix made it into pacman 3.1, and 3.1 didn't have
the above problem.
So now I am confused...

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-22-2008, 10:34 AM
Nagy Gabor
 
Default Fileconflict error...

> On Sat, Jul 19, 2008 at 2:25 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu>
> wrote:
> > Hi!
> >
> > I've tried -Su again...
> > I've just run into a very "hard to fix" error.
> >
> > [ngaba@Arch ~]$ LANG=C sudo pacman -Su --ignore mplayer
> > ...
> > xulrunner: /usr/include/xulrunner-1.9 exists in filesystem
> > xulrunner: /usr/lib/xulrunner-1.9 exists in filesystem
> > xulrunner: /usr/lib/xulrunner-devel-1.9 exists in filesystem
> > xulrunner: /usr/share/idl/xulrunner-1.9 exists in filesystem
> > ...
> >
> > These are directories... But in the package we have symlinks.
> >
>
> I thought this was a regression caused by this fix :
> http://bugs.archlinux.org/task/8156
>
> But apparently this fix made it into pacman 3.1, and 3.1 didn't have
> the above problem.
> So now I am confused...
>

I think this is not a regression, but a behaviour change. What did the
"old" pacman do when we have a real symlink<->dir conflict? I mean a
conflict which won't disappear after the upgrade_remove part:
fileconflict003 should pass.

Bye

P.S.: I will create a pactest for this case.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-22-2008, 11:09 AM
Xavier
 
Default Fileconflict error...

On Tue, Jul 22, 2008 at 12:34 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
>
> I think this is not a regression, but a behaviour change. What did the
> "old" pacman do when we have a real symlink<->dir conflict? I mean a
> conflict which won't disappear after the upgrade_remove part:
> fileconflict003 should pass.
>

Yeah sure, that is why I still called it a fix. It fixed some cases
(the fileconflict003 one), but caused a regression in others (like
xulrunner case).
But right, we can just say behavior change.
Still, I am confused, when did this behavior change?
I thought it was caused by the patch in the above bug report, but this
happened before 3.1.
And apparently 3.1 behavior is different than 3.2, because 3.1 handled
xulrunner upgrade fine, and not 3.2.
Maybe some other changes that happened in 3.2 caused this behavior
change in combination to that "fix for fileconflict003" patch ?

>
> P.S.: I will create a pactest for this case.
>

That would be nice. And even better if you could find out when it broke

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-22-2008, 11:31 AM
Nagy Gabor
 
Default Fileconflict error...

> On Tue, Jul 22, 2008 at 12:34 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu>
> wrote:
> >
> > I think this is not a regression, but a behaviour change. What did
> > the "old" pacman do when we have a real symlink<->dir conflict? I
> > mean a conflict which won't disappear after the upgrade_remove part:
> > fileconflict003 should pass.
> >
>
> Yeah sure, that is why I still called it a fix. It fixed some cases
> (the fileconflict003 one), but caused a regression in others (like
> xulrunner case).
> But right, we can just say behavior change.
> Still, I am confused, when did this behavior change?
> I thought it was caused by the patch in the above bug report, but this
> happened before 3.1.
> And apparently 3.1 behavior is different than 3.2, because 3.1 handled
> xulrunner upgrade fine, and not 3.2.
> Maybe some other changes that happened in 3.2 caused this behavior
> change in combination to that "fix for fileconflict003" patch ?
>
> >
> > P.S.: I will create a pactest for this case.
> >
>
> That would be nice. And even better if you could find out when it
> broke
>

I will go offline until evening. Cannot git be used as a testing
machine (with fileconflict004.py) here?

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-22-2008, 01:20 PM
Xavier
 
Default Fileconflict error...

On Tue, Jul 22, 2008 at 1:31 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
>
> I will go offline until evening. Cannot git be used as a testing
> machine (with fileconflict004.py) here?
>

Hmm reading man git-bisect, this seems possible. We just need some
scripts to return 1 when fileconflict004 fails, and 0 when it pass. It
could be pactest directly after patching it, or just a wrapper on
pactest which greps "PASS = 1" or something like that.

Otherwise you can always manually use fileconflict004 as a test for
doing a bisection using git, but then, it is probably faster to only
do test before any commits related to fileconflict, rather than a
blind testing.

Anyway, I still did a git bisect with manual testing for fun, and the
result is funny

""""
584ffa6aef13d0933ad4930ab9cb70d3af2977ff is first bad commit
commit 584ffa6aef13d0933ad4930ab9cb70d3af2977ff
Author: Dan McGee <dan@archlinux.org>
Date: Mon May 12 20:49:18 2008 -0500

Remove an outdated exception check in file conflict code

This has been around since at least pacman 2.9.8. Frugalware just dumped it
in commit 113ec73bfcfdc, and deleting it here and running pactest shows that
nothing that we have actually tested changes. If someone can pactest the
edge case where this is needed, then show me the money.

Signed-off-by: Dan McGee <dan@archlinux.org>

:040000 040000 ea3e9f52732a5412f2e77e2a1060c3247636de7b
a234d7e4ca725edc301f696640d897ce54dfb3b8 M lib
""""

Well here you go, the pactest is called fileconflict004, courtesy of Nagy

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-22-2008, 06:23 PM
Nagy Gabor
 
Default Fileconflict error...

>
> Signed-off-by: Dan McGee <dan@archlinux.org>
>
> :040000 040000 ea3e9f52732a5412f2e77e2a1060c3247636de7b
> a234d7e4ca725edc301f696640d897ce54dfb3b8 M lib
> """"
>

OMG. That part is totally unrelated here, but it makes our
fileconflict003.py pass (due to its "bug");-). Obviously that won't
solve our problem (unfortunately).

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-22-2008, 06:27 PM
Nagy Gabor
 
Default Fileconflict error...

>
> OMG. That part is totally unrelated here, but it makes our
> fileconflict003.py pass (due to its "bug");-). Obviously that won't
> solve our problem (unfortunately).

typo: fileconflict004.py

For example, this will fail:
----------------------------
self.description = "foo"

p1 = pmpkg("pkg1", "1.0-1")
p1.files = ["test/",
"test/file1"]
self.addpkg2db("local", p1)

p2 = pmpkg("pkg2")
p2.files = ["test/file2"]
self.addpkg2db("local", p2)

p3 = pmpkg("pkg1", "2.0-1")
p3.files = ["test2/",
"test2/file3",
"test -> test2"]
self.addpkg2db("sync", p3)

self.args = "-S pkg1"

self.addrule("PACMAN_RETCODE=1")

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-23-2008, 01:01 AM
"Dan McGee"
 
Default Fileconflict error...

On Tue, Jul 22, 2008 at 8:20 AM, Xavier <shiningxc@gmail.com> wrote:
> On Tue, Jul 22, 2008 at 1:31 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
>>
>> I will go offline until evening. Cannot git be used as a testing
>> machine (with fileconflict004.py) here?
>>
>
> Hmm reading man git-bisect, this seems possible. We just need some
> scripts to return 1 when fileconflict004 fails, and 0 when it pass. It
> could be pactest directly after patching it, or just a wrapper on
> pactest which greps "PASS = 1" or something like that.
>
> Otherwise you can always manually use fileconflict004 as a test for
> doing a bisection using git, but then, it is probably faster to only
> do test before any commits related to fileconflict, rather than a
> blind testing.
>
> Anyway, I still did a git bisect with manual testing for fun, and the
> result is funny

Here is a bisect script I have used with pacman in the past to do it
automatically, I can't remember exactly which bug we were trying to
track down but the ideas here are solid. You need to build, setup your
test environment (if you are using pactest we really don't have to do
much), run the test, and issue the correct exit code.

#!/bin/bash
# make
make
# get setup correct
sudo rm /var/lib/pacman/sync/{community,extra,pacman-git,testing,unstable}/.lastupdate
# remove our temp file
OUTFILE=/tmp/bisectout.txt
[ -f $OUTFILE ] && rm $OUTFILE
# don't want to actually do the upgrade, just see its output
yes n | sudo ./src/pacman/pacman -Syu > $OUTFILE
# if output contains
# warning: licenses: local (2.4-1) is newer than core (2.3-1)
# then it did the wrong thing
grep -qF "warning: licenses: local (2.4-1) is newer than core (2.3-1)"
$OUTFILE && exit 1
# we didn't find our text, good revision
exit 0

>
> """"
> 584ffa6aef13d0933ad4930ab9cb70d3af2977ff is first bad commit
> commit 584ffa6aef13d0933ad4930ab9cb70d3af2977ff
> Author: Dan McGee <dan@archlinux.org>
> Date: Mon May 12 20:49:18 2008 -0500
>
> Remove an outdated exception check in file conflict code
>
> This has been around since at least pacman 2.9.8. Frugalware just dumped it
> in commit 113ec73bfcfdc, and deleting it here and running pactest shows that
> nothing that we have actually tested changes. If someone can pactest the
> edge case where this is needed, then show me the money.
>
> Signed-off-by: Dan McGee <dan@archlinux.org>
>
> :040000 040000 ea3e9f52732a5412f2e77e2a1060c3247636de7b
> a234d7e4ca725edc301f696640d897ce54dfb3b8 M lib
> """"

Hmmmmmm. So what do we need to do here? Put it back in? You guys break
my code too much. :P

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 09:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org