Summary: | net-misc/csync reversion/rename, sys-auth/pam-csync dependency breakage | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Antonino Catinello <ac> |
Component: | Current packages | Assignee: | Bernard Cafarelli <voyageur> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ac, dschridde+gentoobugs, kazer, scarabeus |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=501228 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | csync-0.50.0.ebuild |
Description
Antonino Catinello
2013-08-05 09:06:16 UTC
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. *** |