Index | Thread | Search

From:
izder456 <izder456@disroot.org>
Subject:
Re: NEW: games/Bugdom
To:
Thomas Frohwein <tfrohwein@fastmail.com>
Cc:
ports@openbsd.org
Date:
Mon, 15 Jan 2024 19:15:40 -0600

Download raw body.

Thread
On Mon, 15 Jan 2024 12:56:11 -0500
Thomas Frohwein <tfrohwein@fastmail.com> wrote:

> On Mon, Jan 15, 2024 at 03:33:56PM +0100, izder456 wrote:
> > On 2024-01-15 00:08, izder456 wrote:  
> > > Hey,
> > > 
> > > I would like to import Bugdom (https://github.com/jorio/Bugdom),
> > > which is an old Mac game that has a source port for modern
> > > systems.
> > > 
> > > Its just a simple old Nostalgic game for me, the port can be
> > > found here: (https://github.com/izder456/myports)
> > > 
> > > Comments or OK to import?
> > > --
> > > -iz  
> > 
> > Hey sorry,
> > 
> > Attached in the tarball.
> > 
> > new to port maintenance.
> > 
> > hopefully i packaged this up as i should have.
> > 
> > --
> > -iz  
> 
> Thanks, I think that's a pretty good start. I built it and can run it
> with some modifications (see my attached Makefile). There are some
> things to clarify, here the most important parts:
> 
> 1. The game is licensed CC-BY-NC-SA. CC license is generally *not*
>    recommended for software (see [1]). It looks like a couple of our
>    ports are marked with a CC license. It would be good to hear some
>    other sides on this. The main issue is that it doesn't address
>    redistribution and modification of source code. (This is of course
>    an upstream issue, but affects if we can PERMIT_PACKAGE. Also, the
>    license doesn't seem to be applied to the source code files though
>    that is a common omission on hobbyist GitHub projects.)
> 
> 2. Ports are generally lower case, unless there is a strong reason to
>    avoid that. I don't see that being the case here, so the directory
>    should be changed from games/Bugdom to games/bugdom, and the
> PKGNAME accordingly.
> 
> The rest of my comments are more nits/style things. I recommend to
> start with a copy of Makefile.template (in
> /usr/ports/infrasturcture/templates) which helps keep a certain
> structure that's close to a common style. Here my notes:
> 
> - Tabs seem to be generally preferred over spaces in ports Makefiles.
> - FULLPKGNAME shouldn't be needed; and by default PKGNAME is set to
>   DISTNAME, so some of that is superfluous.
> - You did the legacy way of managing GitHub submodules - I changed it
>   to using DIST_TUPLE in the attached Makefile which simplifies things
>   a lot.
> - Not sure how libsamplerate is used - as it's listed as both build
>   and run dependency, check if it's statically linked?
> - Don't put sdl2 in all 3 *_DEPENDS. Having it as LIB_DEPENDS in this
>   case automatically turns it into build and run dependency (see
>   bsd.port.mk(5)).
> - I've simplified do-install with some globs and removing one
>   unnecessary INSTALL_DATA_DIR.
> - Regarding the script files/bugdom:
>   `cd /usr/local/lib/Bugdom` means that it won't be able to save any
>   core files if run with a normal user (which it should!). Not sure if
>   there is a better way; might have to check with upstream if they can
>   set things up to run the game from a separate location.
> - Is ONLY_FOR_ARCHS=amd64 i386 really needed?
> - portcheck(1) shows: `executable file: files/bugdom`. This should
> best not be executable inside the ports tree and only after
> installation.
> - Lastly, I don't find the COMMENT and pkg/DESCR very useful. Taking a
>   look at [2] and HOMEPAGE, I suggest for COMMENT one of:
> 
>     family-friendly 3D action adventure
>         OR
>     source port of the 3D action adventure Bugdom
> 
> - DESCR could take some cues from [2], for example the text under "The
>   story".
> 
> [1] https://creativecommons.org/faq/
> [2] https://jorio.itch.io/bugdom

Hey again,

Thanks for the reply.

Attached is the changed tarball with the above recommendations.

Some specific notes:

> 1. The game is licensed CC-BY-NC-SA. CC license is generally *not*
>    recommended for software (see [1]). It looks like a couple of our
>    ports are marked with a CC license. It would be good to hear some
>    other sides on this. The main issue is that it doesn't address
>    redistribution and modification of source code. (This is of course
>    an upstream issue, but affects if we can PERMIT_PACKAGE. Also, the
>    license doesn't seem to be applied to the source code files though
>    that is a common omission on hobbyist GitHub projects.)

I would also like to hear other sides with this. I presume it would be
up to Iliyas Jorio and/or Pangea Soft.

I included a trademark and copyright notice in pkg/DESR, unsure if that
is common practice for situations such as this.

> - You did the legacy way of managing GitHub submodules - I changed it
>   to using DIST_TUPLE in the attached Makefile which simplifies things
>   a lot.

I was cross referencing the porting checklist in faq, as well as other
example ports. I probably got overwhelmed by the plethora of
information and mimicked another port out of haste and frustration.

Thanks for the tip! This is way simpler.

> - Regarding the script files/bugdom:
>   `cd /usr/local/lib/Bugdom` means that it won't be able to save any
>   core files if run with a normal user (which it should!). Not sure if
>   there is a better way; might have to check with upstream if they can
>   set things up to run the game from a separate location.

I am no scripting savant, but wouldn't wrapping it in `()` be enough?
Anyways, it seems to be hard-coded to be ran from the same directory as
/Data. It's a bummer cos the other options for packaging aren't
applicable on OpenBSD, Linux AppImages, MacOS appbundles, and exe
bundles.

> - Not sure how libsamplerate is used - as it's listed as both build
>   and run dependency, check if it's statically linked?

No idea, to be honest. I wouldn't know where to start in checking that.
If I had to guess, it's probably got something to to with the Pomme
library this port depends on.

> - Is ONLY_FOR_ARCHS=amd64 i386 really needed?

Unsure on this- I only have amd64 and i386 installs of OpenBSD on hand,
I would like some testing on other architectures if possible.

For the time being, I have removed this line.

I say hold from merge until more testing, 

OK?

-- 
-iz

> If something is shit and no one likes it, 
  you just put out another one the next month.

Stu