Bugzilla Bug 139324

net-misc/neon-0.26.1 should be blocker for net-fs/davfs2

davsf2 doesn't work with neon-0.26.1 and needs 0.24.X or 0.25.X to build.

I changed the dep to <neon-0.26, waiting for upstream to fix this one, I have
not been successfull :(

Reopening this bug, as neon-0.26.1 went stable recently, and now is in full
conflict with davfs2.

davfs2 should block >=neon-0.26.1, one of them needs to be put back in
unstable, or they need to be SLOT'd somehow.

Eh, <net-misc/neon-0.26 works *exactly* as bad as !>net-misc/neon-0.26 if the
block is one-way, if the block is both ways then you get hell more people
ranting b/c of being forced to downgrade and possibly rebuild stuff depending
on it (and the block will still not work correctly afterwards).

Please, go force portage folks to fix Bug 48195 instead of requesting annoying
hacks.

jakub -

I wasn't aware of the relationship to bug #48195.

I don't feel my suggestions were "annoying hacks" -- personally, I find it much
more annoying that davfs2 is now completely broken and unusable because
neon-0.26.1 went stable.

Furthermore, I tested neon-0.26* against davfs2 and subversion-1.3* earlier
this month (check the date the bug was opened), and filed a couple bugs about
the issue.  When that happened I was told, by you, that "Well, honestly that's
what you get for mixing stable and ~arch ebuilds... ;)" bug #139318, comment
#2.

So what do we have now?  "stable" apps that are completely broken.

I used to be a gentoo dev, so I feel I really do understand what is going on. 
I also feel I understand your perspective.  Fixing bug #48195 is the "right
way" to fix this.  What can I say, maybe in two more years, it'll be fixed. 
None of this makes this bug any less annoying for those of us that (used to)
depend on davfs2, to any extent.  If subversion had this issue, because davfs2
required the upgrade, you can imagine what kind of hell would break loose.

I hope this has come across polite, I mean it to be so.  I take part in Gentoo
these days mainly through reporting bugs, so I really do want to be helpful,
and not annoying.

Uhm, you are just requesting something that doesn't work. The blockers are dead
annoying, users file bugs about them over and over again. Deps like
<foo/bar-x.y are ignored. 

Tell usptream to fix davfs2 or package.mask the incompatible neon version - all
we can offer here I'm afraid until Bug 48195 gets fixed. The ebuild is correct
as it is, portage is broken.

Upstreams is working on this issue :
https://sourceforge.net/tracker/?func=detail&atid=386750&aid=1488505&group_id=26275
I'm currently testing the version 1.0.2 v1 locally, found no problems until
now.

nice to see upstream acting on this. Please create a tarball removing the
.svn-dirs. Upload it somewhere (or attach it to the bug) and make an updated
ebuild ready. I can then add those to portage and everyone will be happy :)

Thanks!

Created an attachment (id=94832) [details]
davfs CVS version 1.0.2 v1 

I produced the tarball in that way:
tfoerste@n22 ~ $ cvs -d:pserver:anonymous@dav.cvs.sourceforge.net:/cvsroot/dav
login
Logging in to :pserver:anonymous@dav.cvs.sourceforge.net:2401/cvsroot/dav
CVS password:
tfoerste@n22 ~ $ cvs -z3
-d:pserver:anonymous@dav.cvs.sourceforge.net:/cvsroot/dav checkout -r v1 -P
davfs2
cvs checkout: Updating davfs2
U davfs2/Makefile.in
...
cvs checkout: Updating davfs2/tools
tfoerste@n22 ~ $ tar -cjpf davfs2.tbz2 davfs2/

Created an attachment (id=94833) [details]
console log of make process

I'm not very familar in creating an ebuild.
Using the tarball I did an
$> autogen.sh
followed by an configure call I shameless copied 1:1 from that configure
command what was produced during the configure step of the 0.2.8 ebuild, after
that I made an make && make install and I'm happy.
The full konsole lag is attached.

Created an attachment (id=94843) [details]
davfs2-1.0.2_p20060820.ebuild

please test this.

Created an attachment (id=94844) [details]
davfs2-1.0.2_p20060820.ebuild

please test this.

Copying the 2nd ebuild to my /usr/local/protage overlay and making:
$> https://n22/davfs@n22/ && emerge -a davfs2

compiles and installs it fine, only this might be worth to notice:

---------------------------------------------------
  Congratulations! davfs2 is installed successfully.
----------------------------------------------------

rm: cannot remove `INSTALL': No such file or directory
rmdir: /var/tmp/portage/davfs2-1.0.2_p20060820/image//usr/share/davfs2:
Directory not empty

Looking into /usr/share/davfs2 I have only:
n22 /usr/local/portage/net-fs/davfs2 # ll /usr/share/davfs2
total 24
-rw-r--r-- 1 root root    24 Aug 22 16:26 BUGS
-rw-r--r-- 1 root root 17983 Aug 22 16:26 GPL

IIRC I had more files during manual install, but anyway... Both my local davfs
test environment works fine, production DAV FS can be accessed, the only
(minor) thing I saw immediately after mounting an remote DAVFS was:

$> /sbin/mount.davfs: Connection failed, mounting anyway.  File system will
only be usable when connection comes up.

but the directory content is readable


:-)

well, the last error is an upstream one, I corrected the two others and
committed the ebuild, thanks.

*** Bug 144829 has been marked as a duplicate of this bug. ***