source tarball for pcsx2

[gregory]

Thanks for your help Avih

Will everybody be happy with only a .xz package? Otherwise I'm in favor to keep only bz2. It would be better to remove the 3rdparty directory (because distribution won't be happy with it anyway) which cut by 2 the size of the package. 2-4MB is nothing versus the size of the binary package in the archive ( +30MB).

Dears BSD users, before packaging I think the first step must be
1/ check that PCSX2 compile
2/ check that PCSX2 is able to run

[josephg]

@gregory: I'd prefer xz package, but I can live with bz2, if that's what others prefer. Of course, I'd like to 'hear' from others as well.

@avih: (sorry for long answer here; I wanted it to be as informative as possible to avoid doubts) What you said is correct, but for authorized people (developers and TUs). I'm just an user that contributes to Arch distribution, just like many others, by maintaining packages in Arch User Repository (aur.archlinux.org). That's where currently PCSX2 packages are made available by me for users of archlinux. This AUR website stores only PKGBUILDs (script used to build package for arch). Having that said, I don't have a central storage location for the xz package: each arch user that wants pcsx2 will get my PKGBUILDs and run the compilation, which will download a source tarball from upstream (i.e.: pcsx2) and build locally a PCSX2 package. So, as you probably figure out already, it is because each arch user downloads a source tarball of archlinux that I suggested using a 10Mb tarball (xz) instead of the 14Mb bz2 tarball.

[CeilingCat]

Oh, my. What a wonderful thread about packaging! It is great to see such interest in packaging pcsx2 for these various platforms. Sorry for arriving late to the discussion.

For pkgsrc's part, it doesn't matter what format the distfile archive is - .tar.gz, .tar.bz2, .tar.xz, .7z - pkgsrc supports them all and more. Whatever works best for the majority will be fine for us.

As others have identified, the DDL is pretty important. It saves us having to write and maintain a separate script to fetch the distfile if it cannot be automated. That issue seems to have been resolved.

What is also important is that we can get updated versions of these distfiles. I know you guys don't do official releases that often; however, the latest version of pcsx2 in pkgsrc-wip is 1.0.0r5412, and i'm sure that many fixes have been included since then. It wouldn't make sense to generate a distfile for _every_ commit that you do, because that would likely eat up a lot of space on your hosting. Perhaps, we can come to some agreement regarding the frequency of these versioned distfiles.

I am also in very strong favour of not including the externals in the distfile. pkgsrc has a mechanism to install all the dependencies of the package (via the buildlink framework) and thus bundling them is rather unnecessary for reasons also described by yourself (size of the distfile). If a list of the dependencies is maintained in a README or INSTALL file, this will help other packagers quickly get pcsx2 to build.

WRT making sure that pcsx2 builds before packaging it, pkgsrc has a work-in-progress tree called pkgsrc-wip. If the package is imported there, other people can also work on it. If there are issues with the build, sometimes more hands are better than two at getting it to work. However, i can understand your POV regarding not wanting people to see a non-building version of pcsx2 somewhere. At the same time, if we get regularly versioned distfiles, we can send any failed build reports back to you (possibly even with patches) and help accelerate the development of pcsx2 across platforms.

In short, i'd just like to see 1) DDL to distfile in whatever archive format you choose 2) regularly versioned distfiles.

[avih]

...
In short, i'd just like to see 1) DDL to distfile in whatever archive format you choose 2) regularly versioned distfiles.

Thanks for the info.

Re: regularly versioned etc, we DO use a VCS, yes? which is exactly for such cases where you want regular updates. The tarball is a comfortable replacement if you don't update frequently, as happens with release builds.

If you want regularly updated tarballs, nothing's stopping you from regularly pulling the source, as frequently you like, and package it as appropriate for your system...

[CeilingCat]

You don't understand how these source-based package systems work. We can't just generate a tarball from your HEAD branch, generate the cryptographic hashes of it, and call it a day. Every time that a commit is made, the resulting tarball would have a different checksum and thus our bulk builds will break. This also sets a dangerous precedent for developers as without versioned tarballs we have 1) no accountability regarding what is to be completed before something is versioned 2) no ChangeLog for regression testing and reason for updating the package in the package system 3) no distfile checksums from upstream (you in this case).

This sort of behaviour seems to have become popular with the introduction of github, where everyone thinks it's a great idea to just clone your master branch. I'm not sure what's changed in the development world to make people think this is okay. It's rather bad practice for the reasons outlined above and others.

Which brings us to another point - we can't check out revision X, slap it on our server, and call it your package's version. We're not an official mirror of pcsx2. No one would have any reason to trust whatever is in that distfile and throw it into a compiler.

I have a keen interest in emulators, so other projects who don't version often get bothered by me every so often to generate a reasonably stable revision for packaging. They've been pretty good about it. I've packaged over 10 emulators and counting. In pkgsrc, one of the main package managers is also very interested in emulators and has written one himself. We generally take good care of these packages and want them to build and work well across platform (because we use them).

If this package gets to a point where it's stable enough to be imported into pkgsrc HEAD, then you'd really see some cross-platform testing of pcsx2. We have a team of people who do regular bulk builds of pkgsrc (and even pkgsrc-wip) on various architectures, OSes, versions of those OSes, different versions of pkgsrc, etc. One company heavily invests in pkgsrc development on the SunOS platform.

I suppose the question comes down to how much you care about portability and if it's worth it to you to make these versioned tarballs every so often. If it is, then you'll get a lot of feedback, likely some patches, the development of your project will grow exponentially, and it'll result in a better user experience for end-users on many OSes. It's your call in the end.

[avih]

I'm not sure I understand your suggestion then. What would be an optimal solution from your point of view?

[CeilingCat]

If, let's say, every three months a reasonably stable revision were posted to your official archive (https://code.google.com/p/pcsx2/downloads/list ?). I can't speak for all the packagers in this thread; however, i certainly wouldn't mind if you also sent me an email saying that there's a new version, to package and test it, and provide feedback. Like i said, revision 5412 is in pkgsrc-wip right now and it doesn't build on the platform on which i was testing it.

If this project doesn't get as much traction as others, perhaps every 3 months is too soon and every 6 would be more appropriate. Maybe it's a year. You guys would be the ones to decide. I'm just requesting updated distfiles in a convenient location.

[gregory]

What is exactly distfile for you? Otherwise I'm fine to upload a tarball every 3 months (or approximatively).

We have a lots of OS specfic code so we won't target to run on any OS on earth By the way what graphical stack do you have on BSD? X11? Is binary blob running fine? I know that opensource is very limited.

[CeilingCat]

What is exactly distfile for you?

Distribution file. For example:

https://code.google.com/p/pcsx2/download...es.tar.bz2

Otherwise I'm fine to upload a tarball every 3 months (or approximatively).

That's great to hear!

We have a lots of OS specfic code so we won't target to run on any OS on earth

If for some reason you don't feel like committing our patches, we will still maintain them locally. However, it's usually better if they can be committed upstream. A lot of times, it's just simple #if/#else switches that make a particular header be pulled in.

By the way what graphical stack do you have on BSD? X11?

We do have X11, yes.

Is binary blob running fine? I know that opensource is very limited.

No, that wouldn't be fine at all. Although NetBSD has Linux binary compatibility, if the package is open source, it's generally preferred to build it from source. I can say for sure that OpenBSD is very much against binary blobs.

Looking forward to your next versioned distfile!

[gregory]

No, that wouldn't be fine at all. Although NetBSD has Linux binary compatibility, if the package is open source, it's generally preferred to build it from source. I can say for sure that OpenBSD is very much against binary blobs.

Sorry I miss some word What I mean is: do you have the support of GPU proprietary driver or do you rely on only the opensource driver?