Opened 13 years ago

Closed 13 years ago

#31015 closed enhancement (fixed)

supertux: add app icon

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: adamw@…
Priority: Normal Milestone:
Component: ports Version: 2.0.1
Keywords: haspatch Cc:
Port: supertux

Description

This patch simplifies the supertux port using the new app portgroup and adds an icon to the app bundle. Using the app portgroup also fixes the directory into which the app gets installed.

In addition, the patch makes two other recommended changes: rewriting the dependencies to ensure that non-MacPorts versions of those libraries will not satisfy them, and indicating what license the software is under.

May I commit it?

Attachments (1)

supertux.diff (1.8 KB) - added by ryandesign (Ryan Carsten Schmidt) 13 years ago.
proposed patch

Download all attachments as: .zip

Change History (6)

Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: supertux.diff added

proposed patch

comment:1 Changed 13 years ago by adamw@…

Thank you for preparing this patch. I would be quite happy if you'd apply the patch to add the portgroup, icon, directory fix, and license specification.

However, I do not like rejecting non-MP libraries. I don't like MP assuming that I need extra copies of everything under the sun, but I'll concede that as that is what the MP project wants. However, I see no reason to reject non-MP libraries if a user chooses not to install redundant versions. Please by all means commit the other changes.

Thanks so much.

# Adam

comment:2 in reply to:  1 Changed 13 years ago by danielluke (Daniel J. Luke)

Replying to adamw@…:

However, I do not like rejecting non-MP libraries.

So, how do you plan on fixing this problem?

  • User has libmikmod installed somewhere and your port uses it. User uninstalls libmikmod because he/she no longer needs it for whatever purpose it was originally installed. Result -> your port is broken.

If the port installed libmikmod to satisfy the dependency, and the user goes to uninstall it, MacPorts will let them know that your port requires it (and will only uninstall if forced with '-f')

Similarly, how do you handle when the user decides to 'upgrade' to a non binary compatible version of a library you depend on?

Using MacPorts to handle the dependencies helps to prevent a lot of potential brokenness...

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

Replying to adamw@…:

Thank you for preparing this patch. I would be quite happy if you'd apply the patch to add the portgroup, icon, directory fix, and license specification.

Thanks, committed in r83337.

However, I do not like rejecting non-MP libraries. I don't like MP assuming that I need extra copies of everything under the sun, but I'll concede that as that is what the MP project wants. However, I see no reason to reject non-MP libraries if a user chooses not to install redundant versions.

This is basically a policy decision the MacPorts project made long ago, for reasons explained in FAQ, those voiced by Daniel above, and others. It reduces our support burden and makes things more likely to "just work" by reducing the number of possible user configurations. (If the libsdl on the user's system did not come from MacPorts, who knows what version it is or what architecture it is.) I would like to apply this fix to the portfile as well, because users will not expect that supertux deviates from this standard MacPorts behavior.

comment:4 Changed 13 years ago by adamw@…

Well, though I am not a fan of the perspective (I'd much rather have a "switch" that would let me use preexisting libraries [at my own peril] without having to gut every Portfile, and not install libraries unless they don't already exist), I am certainly not going to argue in a ticket. As committers you understand best the policies and perspectives of the MP project, so please DTRT with the SuperTux dependencies. I hope you don't see me dragging my feet as challenging your need to maintain consistency.

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

Resolution: fixed
Status: newclosed

The problem with adding a switch to let users do things at their peril is that they activate the switch, experience the peril, then write to us asking for help, wasting our time.

There's been a discussion on this topic on the mailing list again recently. If you'd like to voice your opinion on it, the mailing list would be a better place than this ticket; you'll get a larger audience.

I've applied the remainder of the patch in r83932.

Note: See TracTickets for help on using tickets.