Update rdiff-backup from 0.12.8 to 1.0.1: * pkg-message not needed anymore, 1.0.x originated from the development branch 0.13.x, btw there is no development branch anymore * this update includes the change in ports/84571 and ports/84978 which have not yet been commited * no need to set DOCSDIR to its default value * sync pkg-plist I guess maintainer timeout should be considered, as we did not get reply from steve@ion.lu (maintainer) for: * ports/84571 (opened 05 Aug, closed 20 Aug, maint. was CC'd) * ports/84978 (opened 16 Aug, still open, maint. was CC'd) * subsequent question from Sam Lawrance about ports/84978 on 31 Aug.
Responsible Changed From-To: freebsd-ports-bugs->lawrance Take it
On Wed, 14 Sep 2005 14:09:26 +0300 Vasil Dimov <vd@datamax.bg> wrote: > I guess maintainer timeout should be considered, as we did not get > reply from steve@ion.lu (maintainer) for: > * ports/84571 (opened 05 Aug, closed 20 Aug, maint. was CC'd) > * ports/84978 (opened 16 Aug, still open, maint. was CC'd) > * subsequent question from Sam Lawrance about ports/84978 on 31 Aug. Yes, I will apply the timeout from ports/84978 to this PR. No sense in pushing it back another 14 days just because you've done more work. Before I go ahead though, Peter Schuller (maintainer of rdiff-backup-devel) noted that this version and the last version of rdiff-backup are incompatible. Since people may have the old version in use for some while, he suggested we might want to keep the rdiff-backup port around for a while (perhaps, for example, by creating rdiff-backup1). Have a think about it; I'll email you both soon and we'll decide a way to go.
On Thu, Sep 15, 2005 at 01:48:26AM +1000, Sam Lawrance wrote: > On Wed, 14 Sep 2005 14:09:26 +0300 > Vasil Dimov <vd@datamax.bg> wrote: > > I guess maintainer timeout should be considered, as we did not get > > reply from steve@ion.lu (maintainer) for: > > * ports/84571 (opened 05 Aug, closed 20 Aug, maint. was CC'd) > > * ports/84978 (opened 16 Aug, still open, maint. was CC'd) > > * subsequent question from Sam Lawrance about ports/84978 on 31 Aug. > > Yes, I will apply the timeout from ports/84978 to this PR. No sense in > pushing it back another 14 days just because you've done more work. > > Before I go ahead though, Peter Schuller (maintainer of > rdiff-backup-devel) noted that this version and the last version of > rdiff-backup are incompatible. Since people may have the old version > in use for some while, he suggested we might want to keep the > rdiff-backup port around for a while (perhaps, for example, by creating > rdiff-backup1). Have a think about it; I'll email you both soon and > we'll decide a way to go. This is what we have: [time] | v | 0.12.x (stable) in sysutils/rdiff-backup 0.13.x (unstable) in sysutils/rdiff-backup-devel | v | 1.0.1 (stable), originated from 0.13.x (no unstable branch) My suggestion would be to upgrade rdiff-backup port from 0.12.x to 1.0.1 and to drop rdiff-backup-devel port - this better reflects the actual situation. BUT we have the problem with incompatibilities - the old and the new version of the rdiff-backup port (0.12.x and 1.0.1) would be incompatible. One possible solution is to: * rename rdiff-backup to rdiff-backup-old, rdiff-backup-012 or something else, or even drop it - just like the developers of rdiff-backup did with the 0.12.x branch. * rename rdiff-backup-devel to rdiff-backup and upgrade it from 0.13.x to 1.0.1 We have the problem, mentioned above: rdiff-backup goes from 0.12.x to 1.0.1 Another solution: * create rdiff-backup1 port for 1.x branch and mark rdiff-backup and rdiff-backup-devel as deprecated/for deletion and forward users to rdiff-backup1 * wait * delete rdiff-backup and rdiff-backup-devel * possibly wait * rename rdiff-backup1 to rdiff-backup This seems more difficult, but less destructive.
I would just like to point out another possible complication, namely that, based on the phrasing on the rdiff-backup website, there may be an unstable branch of rdiff-backup again in the future. One might want to keep this in mind when deciding on a course of action, to avoid having to "re-arrange" the rdiff-backup(-devel) port(s) again in the future. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
Peter Schuller wrote: >I would just like to point out another possible complication, namely >that, based on the phrasing on the rdiff-backup website, there may >be an unstable branch of rdiff-backup again in the future. One might >want to keep this in mind when deciding on a course of action, to >avoid having to "re-arrange" the rdiff-backup(-devel) port(s) again >in the future. > > Ok I was reading posts upside down, sorry for that. I agree to Peter's thought. In this case there is no ideal way. A sysadmin should anyways not do something like: portupgrade -Rra I usually do: portupgrade -Rran |grep + Analyze the output and the do the updates that are "safe" automatically and the updates that need manually backupping etc manually. Updating the port to 1.0.1 would be the way to go. cheers, Steve C -- ION Network Solutions Steve Clement Unix System Administrator 209, rue des Romains L-8041 Bertrange Tel: +352 261 276-2 Fax: +352 261 276-9 mailto:steve@ion.lu http://www.ion.lu
On Thu, 29 Sep 2005 17:39:43 +0200 Steve Clement <steve@ion.lu> wrote: > Peter Schuller wrote: > > >I would just like to point out another possible complication, namely > >that, based on the phrasing on the rdiff-backup website, there may > >be an unstable branch of rdiff-backup again in the future. One might > >want to keep this in mind when deciding on a course of action, to > >avoid having to "re-arrange" the rdiff-backup(-devel) port(s) again > >in the future. > > > > > Ok I was reading posts upside down, sorry for that. > > I agree to Peter's thought. > > In this case there is no ideal way. A sysadmin should anyways not do > something like: > > portupgrade -Rra > > I usually do: portupgrade -Rran |grep + > > Analyze the output and the do the updates that are "safe" > automatically and the updates that need manually backupping etc > manually. > > Updating the port to 1.0.1 would be the way to go. I've had some feedback from a couple other users who think the port should just be updated, and I tend to agree. How's this: - send a little heads-up to ports@ - update rdiff-backup port to 1.0.1 and add information about the incompatibility to ports/UPDATING - retire rdiff-backup-devel, and add an entry to ports/MOVED so that rdiff-backup-devel users are migrated to 1.0.1 of rdiff-backup.
On Tue, Oct 04, 2005 at 04:29:34PM +1000, Sam Lawrance wrote: > On Thu, 29 Sep 2005 17:39:43 +0200 > Steve Clement <steve@ion.lu> wrote: > > > Peter Schuller wrote: > > > > >I would just like to point out another possible complication, namely > > >that, based on the phrasing on the rdiff-backup website, there may > > >be an unstable branch of rdiff-backup again in the future. One might > > >want to keep this in mind when deciding on a course of action, to > > >avoid having to "re-arrange" the rdiff-backup(-devel) port(s) again > > >in the future. > > > > > > > > Ok I was reading posts upside down, sorry for that. > > > > I agree to Peter's thought. > > > > In this case there is no ideal way. A sysadmin should anyways not do > > something like: > > > > portupgrade -Rra > > > > I usually do: portupgrade -Rran |grep + > > > > Analyze the output and the do the updates that are "safe" > > automatically and the updates that need manually backupping etc > > manually. > > > > Updating the port to 1.0.1 would be the way to go. > > I've had some feedback from a couple other users who think the port > should just be updated, and I tend to agree. > > How's this: > > - send a little heads-up to ports@ OK > - update rdiff-backup port to 1.0.1 and add information about the > incompatibility to ports/UPDATING OK > - retire rdiff-backup-devel, and add an entry to ports/MOVED so that > rdiff-backup-devel users are migrated to 1.0.1 of rdiff-backup. Maybe it's better not to rush deleting rdiff-backup-devel, but instead mark it as "IGNORE=please migrate to rdiff-backup" for some time and then delete it, because: 1. In case -devel branch is released (again) by the rdiff-backup developers (like Peter Schuller suggested), avoid deleting/creating the same port multiple times. 2. Help users understand what's happening, (I gues few of them will start digging in ports/MOVED to see where their port disappeared :) 3. This is generally less destructive operation than just dropping the port without notice.
On Tue, 4 Oct 2005 10:56:14 +0300 Vasil Dimov <vd@datamax.bg> wrote: > On Tue, Oct 04, 2005 at 04:29:34PM +1000, Sam Lawrance wrote: > > On Thu, 29 Sep 2005 17:39:43 +0200 > > Steve Clement <steve@ion.lu> wrote: > > > > > Peter Schuller wrote: > > > > > > >I would just like to point out another possible complication, > > > >namely that, based on the phrasing on the rdiff-backup website, > > > >there may be an unstable branch of rdiff-backup again in the > > > >future. One might want to keep this in mind when deciding on a > > > >course of action, to avoid having to "re-arrange" the > > > >rdiff-backup(-devel) port(s) again in the future. > > > > > > > > > > > Ok I was reading posts upside down, sorry for that. > > > > > > I agree to Peter's thought. > > > > > > In this case there is no ideal way. A sysadmin should anyways not > > > do something like: > > > > > > portupgrade -Rra > > > > > > I usually do: portupgrade -Rran |grep + > > > > > > Analyze the output and the do the updates that are "safe" > > > automatically and the updates that need manually backupping etc > > > manually. > > > > > > Updating the port to 1.0.1 would be the way to go. > > > > I've had some feedback from a couple other users who think the port > > should just be updated, and I tend to agree. > > > > How's this: > > > > - send a little heads-up to ports@ > OK > > > - update rdiff-backup port to 1.0.1 and add information about the > > incompatibility to ports/UPDATING > OK > > > - retire rdiff-backup-devel, and add an entry to ports/MOVED so that > > rdiff-backup-devel users are migrated to 1.0.1 of rdiff-backup. > > Maybe it's better not to rush deleting rdiff-backup-devel, but instead > mark it as "IGNORE=please migrate to rdiff-backup" for some time and > then delete it, because: > 1. In case -devel branch is released (again) by the rdiff-backup > developers (like Peter Schuller suggested), avoid deleting/creating > the same port multiple times. It's very easy to resurrect it from CVS history if the need arises. > 2. Help users understand what's happening, (I gues few of them will > start digging in ports/MOVED to see where their port disappeared :) MOVED is used by tools like portupgrade, so there should be no problems. From what I gather, rdiff-backup-devel users will simply be moved to the release version of what they have been using all this time. > 3. This is generally less destructive operation than just dropping > the port without notice. Not if there's a suitable alternative available. And IMO it's better to move users from rdiff-backup-devel to rdiff-backup now. If another development branch is started later and there are incompatibilites, they'll cop it then. What do you think?
On Tue, Oct 04, 2005 at 06:14:13PM +1000, Sam Lawrance wrote: > On Tue, 4 Oct 2005 10:56:14 +0300 > Vasil Dimov <vd@datamax.bg> wrote: > > > On Tue, Oct 04, 2005 at 04:29:34PM +1000, Sam Lawrance wrote: > > > On Thu, 29 Sep 2005 17:39:43 +0200 > > > Steve Clement <steve@ion.lu> wrote: > > > > > > > Peter Schuller wrote: > > > > > > > > >I would just like to point out another possible complication, > > > > >namely that, based on the phrasing on the rdiff-backup website, > > > > >there may be an unstable branch of rdiff-backup again in the > > > > >future. One might want to keep this in mind when deciding on a > > > > >course of action, to avoid having to "re-arrange" the > > > > >rdiff-backup(-devel) port(s) again in the future. > > > > > > > > > > > > > > Ok I was reading posts upside down, sorry for that. > > > > > > > > I agree to Peter's thought. > > > > > > > > In this case there is no ideal way. A sysadmin should anyways not > > > > do something like: > > > > > > > > portupgrade -Rra > > > > > > > > I usually do: portupgrade -Rran |grep + > > > > > > > > Analyze the output and the do the updates that are "safe" > > > > automatically and the updates that need manually backupping etc > > > > manually. > > > > > > > > Updating the port to 1.0.1 would be the way to go. > > > > > > I've had some feedback from a couple other users who think the port > > > should just be updated, and I tend to agree. > > > > > > How's this: > > > > > > - send a little heads-up to ports@ > > OK > > > > > - update rdiff-backup port to 1.0.1 and add information about the > > > incompatibility to ports/UPDATING > > OK > > > > > - retire rdiff-backup-devel, and add an entry to ports/MOVED so that > > > rdiff-backup-devel users are migrated to 1.0.1 of rdiff-backup. > > > > Maybe it's better not to rush deleting rdiff-backup-devel, but instead > > mark it as "IGNORE=please migrate to rdiff-backup" for some time and > > then delete it, because: > > 1. In case -devel branch is released (again) by the rdiff-backup > > developers (like Peter Schuller suggested), avoid deleting/creating > > the same port multiple times. > > It's very easy to resurrect it from CVS history if the need arises. > > > 2. Help users understand what's happening, (I gues few of them will > > start digging in ports/MOVED to see where their port disappeared :) > > MOVED is used by tools like portupgrade, so there should be no > problems. From what I gather, rdiff-backup-devel users will simply be > moved to the release version of what they have been using all this time. > > > 3. This is generally less destructive operation than just dropping > > the port without notice. > > Not if there's a suitable alternative available. And IMO it's better > to move users from rdiff-backup-devel to rdiff-backup now. If another > development branch is started later and there are incompatibilites, > they'll cop it then. > > What do you think? Great, just do it.
State Changed From-To: open->closed Committed, thanks all!