Opened 13 years ago

Closed 13 years ago

#30174 closed update (fixed)

centerim - update to 4.22.10

Reported by: miwi@… Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 1.9.2
Keywords: haspatch Cc:
Port: centerim

Description

Hi,

here is a security update to 4.22.10, also i'd like to maintain this port.

Attachments (3)

centerim.diff (1.3 KB) - added by miwi@… 13 years ago.
centerim.ryandesign.novariants.diff (3.2 KB) - added by ryandesign (Ryan Carsten Schmidt) 13 years ago.
proposed patch for no variants
centerim.ryandesign.cleanervariants.diff (2.9 KB) - added by ryandesign (Ryan Carsten Schmidt) 13 years ago.
alternate proposal for cleaned-up variants

Download all attachments as: .zip

Change History (7)

Changed 13 years ago by miwi@…

Attachment: centerim.diff added

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned

Thanks.

comment:2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

In r80554 I made you the maintainer and indicated the license (including the version of the license). That leaves the version update. But when I looked at the port, I didn't like its existing variants. It has an +msn variant (which enables msn support) and an +allproto variant (which enables msn and yahoo support). For both variants, the only added dependency is curl. I would much prefer if the port would just enable support for all protocols all the time, without requiring the user to mess with variants. I've attached a proposed patch.

Alternately, if the variants are to be kept, they should be cleaned up. It does not make sense that msn support is available separately but yahoo support is not. One option is for msn and yahoo support to each be their own variants. The allproto variant can be kept for now to facilitate upgrades, and removed later. I've attached a patch implementing this proposal which also factors out common code from the variants. Another choice would be to have a single variant which enables both msn and yahoo support, since once you add one, there is no additional cost for also building the other. I did not write a patch for this option.

Separately, what do you want to do about the centerim-devel port? Do you want to keep that updated with newer development versions of centerim, or should we declare it dead and mark it replaced_by centerim?

Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

proposed patch for no variants

Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

alternate proposal for cleaned-up variants

comment:3 in reply to:  2 ; Changed 13 years ago by miwi@…

Replying to ryandesign@…:

In r80554 I made you the maintainer and indicated the license (including the version of the license). That leaves the version update. But when I looked at the port, I didn't like its existing variants. It has an +msn variant (which enables msn support) and an +allproto variant (which enables msn and yahoo support). For both variants, the only added dependency is curl. I would much prefer if the port would just enable support for all protocols all the time, without requiring the user to mess with variants. I've attached a proposed patch.

please go with this patch.

Alternately, if the variants are to be kept, they should be cleaned up. It does not make sense that msn support is available separately but yahoo support is not. One option is for msn and yahoo support to each be their own variants. The allproto variant can be kept for now to facilitate upgrades, and removed later. I've attached a patch implementing this proposal which also factors out common code from the variants. Another choice would be to have a single variant which enables both msn and yahoo support, since once you add one, there is no additional cost for also building the other. I did not write a patch for this option.

Separately, what do you want to do about the centerim-devel port? Do you want to keep that updated with newer development versions of centerim, or should we declare it dead and mark it replaced_by centerim?

the development is very slow, we should declare it dead.

thx for the rework,

  • Martin

comment:4 in reply to:  3 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

Replying to miwi@…:

please go with this patch.

r80591

the development is very slow, we should declare it dead.

r80592

Note: See TracTickets for help on using tickets.