Vice PBI

[pcbsd64]

I am submitting these files as they are the content of ~/EasyPBI/Modules/Vice after creating vice-2.3_4-amd64.pbi, which can be found here : http://www.clbb.net/~chris/vice-2.3_4-amd64.pbi
shasum : http://www.clbb.net/~chris/vice-2.3_4-amd64.pbi.sha256

The module files do not contain anything that would enable ethernet emulation in Vice as I had to edit the makefile in ports before building the PBI There would be no point in adding them to the build server, but the PBI itself does install an ethernet enabled Vice emulator with Simple DirectMedia Layer support. You could chose to add it as is to the AppCafe or rebuild the existing Vice PBI with the makefile edited for "--enable-ethernet" and add "WITH_SDL=yes" in Module Build Options.

[pcbsd64]

It has been pointed out to me that the procedure for submitting a PBI is to create a module from a FreeBSD port and submit that module to a mailing list for approval and addition to a bulid server.

I have to ask, what is there to approve and why even get users to build the module first, when the outcome or finished PBI is completely controlled by the current version of the FreeBSD port? Why not just build PBI's of all the FreeBSD ports and be done with it.

I had mistakenly believed that PBI's were user generated customizations that the PCBSD community could share in, if they found them useful. Similar to the Arch User Repository for Arch Linux.

If I want to change anything about a PBI, to make it more useful, I need to have that change first implemented by the maintainer of the port, then the PBI can be built including that change. I don't see any difference, then, other than the location of files, from installing a PBI or installing from ports.

There should be a way for Applications that are not in ports to run on PCBSD. gPodder 2 for example, is not in ports. It has been replaced by gPodder 3, which does not interface with a "mp3 player" device for listening to the podcast away from your computer. It would be nice to have a PBI of gPodder2, we used to, but now we can't because its not in ports.

I don't believe that this inclusion of PBI's that are not sanctioned by FreeBSD developers would fork the PCBSD project. It might even make it more popular.

[Beanpole]

I have to ask, what is there to approve and why even get users to build the module first, when the outcome or finished PBI is completely controlled by the current version of the FreeBSD port? Why not just build PBI's of all the FreeBSD ports and be done with it.

In general, that is what most of the PBI's currently in the AppCafe right now are, just FreeBSD ports repackaged as PBI's. The reason that PBI's go through the approval process, is that some ports do not handle the default conversion into a PBI very well and need some minor tweaking (handled directly from the PBI module, not modifying the port at all). Some examples of this are: including missing dependencies, adjusting python/ruby script headers to point to the proper python/ruby version contained in the PBI, adding desktop/menu entries for specific binaries, etc...

I had mistakenly believed that PBI's were user generated customizations that the PCBSD community could share in, if they found them useful. Similar to the Arch User Repository for Arch Linux.

In general, the PBI format is just that, a packaging format only. There is nothing preventing anyone from creating PBI's out of whatever customized ports/programs that they would like, and then distributing those PBI's to whomever they wish (there are even handy tools for creating/managing your own PBI repositories included on your PC-BSD system!) The general rule for the official PC-BSD repository is to simply stick with an unmodified FreeBSD ports tree, and only use currently supported/maintained versions of programs by doing so. One good reason for this is to cut down on the amount of man-hours required to keep our PBI's current, while utilizing the contributions of the multitude the FreeBSD port commiters and maintainers. I personally feel that by making PBI's out of FreeBSD ports, I am helping those who created that program or port to distribute their work to the general public in an easy to use format.

If I want to change anything about a PBI, to make it more useful, I need to have that change first implemented by the maintainer of the port, then the PBI can be built including that change. I don't see any difference, then, other than the location of files, from installing a PBI or installing from ports.

To get an "unsanctioned" program change into a PBI supplied through the official PC-BSD repository, we simply ask that you first submit your change(s) to the current maintainer of the respective FreeBSD port. This in no way prevents you from building, using, or distributing any "custom" PBI that you desire (even if it is not built from FreeBSD port). Alternatively, we believe that asking people to submit their changes to the FreeBSD port maintainer helps people contribute to the FreeBSD (and PC-BSD) system as a whole, rather than restricting the benefit of your changes to a smaller "ecosystem" of users.

There should be a way for Applications that are not in ports to run on PCBSD. gPodder 2 for example, is not in ports. It has been replaced by gPodder 3, which does not interface with a "mp3 player" device for listening to the podcast away from your computer. It would be nice to have a PBI of gPodder2, we used to, but now we can't because its not in ports.

As I mentioned earlier, the PBI is just a packaging format. As long as you build your PBI on a PC-BSD 9.x system, it is (almost) guaranteed to work on any other PC-BSD 9.x system. Once the PBI is actually created, there is no distinction between PBI built from ports, and PBI's built from local sources.
While the PC-BSD repository currently only builds from FreeBSD ports, there is no strict requirement that we cannot include PBI's from other sources (aside from the time/maintainership issues mentioned above). As an example, I would recommend taking a look at the (nonport) module that we use to build the Minecraft PBI[1]. While it does use ports for some dependancies, the main scripts are completely unique to that particular PBI module. This does not modify or change the program in any way, but simply performs the necessary steps to set up the program to run properly.

[1] http://trac.pcbsd.org/browser/pbi/mo...port/minecraft

I don't believe that this inclusion of PBI's that are not sanctioned by FreeBSD developers would fork the PCBSD project. It might even make it more popular.

I couldn't agree more. I look forward to the day when there are tons of PBI repositories available to users, ranging from developers hosting their commercial applications to your standard users publishing their "enhanced" versions of free software.

[pcbsd64]

Thank you for your thoughtful and considerate response, Beanpole.

I have sent a second email to dionex@freshports.org with Makefile attached. I have also posted a link to my Vice customization PBI on my Commodore Server blog.

The idea of a gPodder PBI still interests me. There really should be 2 gPodder ports, one for version 2 as well as version 3. It is this way in most linux repositories.

Version 3 was made without device sync and I beleive their developers were going for an andriod type app which of course would not need to sync with an external device since it would already reside on one. Which begs the question "who runs FreeBSD on their hand-held device?"

In any case I would like to attempt a gPodder 2 PBI. I'm guessing that all I need do is to set up a ~/ports directory with all the necessary files and aim EasyPbi at it to choose it as a port.

[Beanpole]

The idea of a gPodder PBI still interests me. There really should be 2 gPodder ports, one for version 2 as well as version 3. It is this way in most linux repositories.

Version 3 was made without device sync and I beleive their developers were going for an andriod type app which of course would not need to sync with an external device since it would already reside on one. Which begs the question "who runs FreeBSD on their hand-held device?"

In any case I would like to attempt a gPodder 2 PBI. I'm guessing that all I need do is to set up a ~/ports directory with all the necessary files and aim EasyPbi at it to choose it as a port.

I would recommend seeing if you can simply make a FreeBSD port for gPodder2 first. There are many program that have multiple ports for different versions, and I think your reasons for making a gPodder2 port are perfectly valid. The only objection that I would expect the FreeBSD port folks to make is that gpodder2 is no longer maintained at the source (for bugfixes, etc). So if you could find either a fork or one of the linux distributions that maintain their version of gpodder 2, that will go a long way toward convincing them that it is worthwhile to have both versions in the ports tree. It is at least worth a shot, especially if you have already gone through all the trouble of modifying the ports tree just to build the PBI in the first place.

To answer your question though; Yes, you just need to modify the ports tree on your local system and point EasyPBI (or use the pbi_* CLI tools) at that tree in order to create customized PBI's (using the FreeBSD ports as a base).

[pcbsd64]

I was unable to find a currently maintained gpodder 2, but I was able to

python setup.py install

in mygpoclient-1.6, feedparser-5.1.2 and gpodder-2.20.1