There is obviously a wrong name and version declaration of the package csync in portage. The ebuild of csync-0.80.0 is using the source archive of a csync fork called ocsync which is part of the owncloud project. Andreas Schneider who is a developer of csync just confirmed this and pointed me to the following notice for clarification. https://dragotin.wordpress.com/2013/08/05/csync-upstream-release-0-50-0/ On 1st August version 0.50.0 was released. http://www.csync.org/2013/08/01/csync-version-0-50-0/ So maybe the ebuilds of the fork should be renamed to ocsync to have proper names and versions in portage? Reproducible: Always
How should we fix this? Just rename the package ocsync (remembering that we would no longer be able to reuse the original package name)? Alternatively, we could create a new ocsync package and bump real csync (which would be presented to the user as a downgrade).
Why is the package name not reusable at a later point? Is this a portage limitation? I think in that case your approach may be the best solution. Keeping in mind that all ebuilds that depend on csync (ocsync) have to be fixed as well.
(In reply to Antonino Catinello from comment #2) > Why is the package name not reusable at a later point? Is this a portage > limitation? If we move/rename csync -> ocsync, it will not just be renamed in the tree, but automatically renamed on everyone's system too. If we then re-created the csync package, the package would just be automatically moved again. > I think in that case your approach may be the best solution. Keeping in mind > that all ebuilds that depend on csync (ocsync) have to be fixed as well. There are only currently two dependants, so it is only a small amount of work.
Created attachment 355230 [details] csync-0.50.0.ebuild This is an ebuild for csync-0.50.0.
(In reply to Michael Palimaka (kensington) from comment #3) > (In reply to Antonino Catinello from comment #2) > > Why is the package name not reusable at a later point? Is this a portage > > limitation? > If we move/rename csync -> ocsync, it will not just be renamed in the tree, > but automatically renamed on everyone's system too. If we then re-created > the csync package, the package would just be automatically moved again. > > > I think in that case your approach may be the best solution. Keeping in mind > > that all ebuilds that depend on csync (ocsync) have to be fixed as well. > There are only currently two dependants, so it is only a small amount of > work. Well you could also move net-misc/csync to net-misc/ocsync and introduce csync in another category afterwards (like app-misc)
I would rather csync-* not be reused anytime soon. Yes, I know this is a problem, but it will mess up current users' systems to have a rename and then add the new one, and the most appropriate category seems to be net-misc/.
We should action this sooner rather than later, see bug #483696 comment 7.
I will do the straight rename soon if nobody objects.
This is (partly, without a package move) InOverlay, see bug #494314 comment #5.
Thanks everyone in this bug, this is now fixed in main tree owncloud-client (moved from mirall) simply now depends on net-misc/ocsync, and csync is the correct upstream version.
Some fallout from the renaming: RepoMan scours the neighborhood... dependency.bad 20 sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/developer) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(default/linux/x86/13.0) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(default/linux/x86/13.0/desktop) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(default/linux/x86/13.0/desktop/gnome) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(default/linux/x86/13.0/desktop/gnome/systemd) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(default/linux/x86/13.0/desktop/kde) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(default/linux/x86/13.0/desktop/kde/systemd) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(default/linux/x86/13.0/developer) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(hardened/linux/amd64) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/no-multilib) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/selinux) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(hardened/linux/x86) ['>=net-misc/csync-0.60.0'] sys-auth/pam-csync/pam-csync-0.42.0-r1.ebuild: RDEPEND: ~x86(hardened/linux/x86/selinux) ['>=net-misc/csync-0.60.0']
Thanks patrick, I had not seen pam-csync was patched to support ocsync, and not the original csync. Fixed dependency
*** Bug 501228 has been marked as a duplicate of this bug. ***
