AuthorTopic: Packaging newbie (Read 9834 times)

As there are a number of documents and threads around this complex and I think I've read most of them and still aren't sure, I'll just post this here, feel free to move it anywhere else more appropriate.

A few questions:

1) Say I've searched the forum for an app that I didn't find and will try to package. Where should I post which app I will attempt to package? This would be in order to avoid overlapping build attempts.

3) If I managed to build the package (let's see if I get there at all;)), where would I post it? Toothandnail seems to post about any new packages in the testing repo, so should I send him a PM or something?

4) NExt step: somebody will upload my package (etc.) to the repo???

5) The next step would be test phase I guess: community members will try to download my package and test it on their systems?

I've done a few packages but still consider myself very much a packaging newbie.

1) I asked the same thing a while ago and at that time, it seemed there wasn't a consistent way to find out if someone is working on something you're interested in packaging. I guess whoever finishes it first wins.

2) Always search five places in the repo to see if the package is already there. Those would be the standard four plus testing. There is also an unstable repo but I've never looked there. Maybe something problematic and thus in progress would be there. I guess I should check it out. If an older version of a package is in the repo, feel free to package a newer version. You can probably reuse the SlackBuild script for the old package after a few tweaks.

3) Packages have to be built according to definite rules in order to be acceptable for the repos. Contact JohnB316 by personal message and find out what you have to do. You'll get instructions for submitting your package to the packagers board (a private section just for packagers).

4) After your package is submitted and inspected to make sure everything needed is included, it will be posted to testing.

5) If there is no negative feedback, the package will be moved out of testing and into the general repos.

6) The fundamental thing about packaging is that you *must* build a package on a clean box. That means VectorLinux 6 Light (preferably) as it comes out of the box with no additional programs that might add libraries to the library paths or other dependencies. Also no proprietary drivers (such as NVidia or ATi proprietary drivers). Updating packages already in the out-of-the-box installation is okay. So you pretty much need either a separate partition or a separate computer for packaging. If you package on a "dirty" box, compiling can create fake dependencies that could install unnecessary things on people's computers. The slapt-get system pulls down necessary dependencies when the package is installed, and those dependencies should be NECESSARY and not fake.

1) there's a packagers forum where you can post when you're working on something. It's only for users labeled as 'packagers'.

2) an easier way is enabling all vl6 repos (extra, packages and testing IIRC) in your slapt-getrc file. then just slapt-get --search XYZ. if it's not there, it means we don't have it. Remember slapt-get --update frequently .

3) if you want, you can contact any active packager and send him/her your first packages. Experienced packagers can give you some hints and will examine your first packages.

I've exclusively installed VL Light 6.0 on an old laptop so it's definitely a clean system .

I'll have a look at stretchedthin's screencast and follow your instructions as well and then I'll probably try and do an "easy" package with just one tarball and as few dependencies as possible for a test. It might not be something ultra-useful to everyone out there, but I think it's probably a good start.

I'll have a look at stretchedthin's screencast and follow your instructions as well and then I'll probably try and do an "easy" package with just one tarball and as few dependencies as possible for a test. It might not be something ultra-useful to everyone out there, but I think it's probably a good start.

There are lots of packages that are a matter of ./configure && make install , so default script generated by sbbuilder will work out of the box. I only have to fill the documentation part for most of my packages.

And yes, that's the way to go. Start easy, and increase difficulty little by little.

I think the files in usr/doc/gtkperf are generated by the application itself, while the SlackBuild generates usr/doc/gtkperf-0.4.0You can delete the first dir or just move the files to usr/doc/gtkperf-0.4.0

If you have a direct link to the sources, please feed it in the $LINK variable at the top of the SlackBuild or use --link with sbbuilder. In that way will be easier for others to replicate your package or reuse the script later (for example, rebuilding for the 64bits architecture.)

Traditionally the graphical applications ship a .desktop file that provides an entry for the menu. However this is not mandatory, sometimes the custom is to launch an application from the command line. I never used this app before but if it is usually launched from the menu a .desktop file should be provided. The latest sbbuilder version has a --xdesktop option that places a template for you in the SlackBuild for a regular .desktop file. You have to edit it as needed. Another way is to place the .desktop file with the source and copy it into the proper location from the script.If in doubt, just provide a menu entry.

Good work, and thanks for your contribution

Logged

"There is a concept which corrupts and upsets all others. I refer not to Evil, whose limited realm is that of ethics; I refer to the infinite."Jorge Luis Borges, Avatars of the Tortoise. --Jumalauta!!

The other concern is that the install is not sending the png image to /usr/share/pixmaps/and is not sending the .desktop file to /usr/share/applications/so your application is not showing up in the menu.

The is a section in the sbbuilder slackbuild that looks like this...########################################################################Miscellenious tweaks and things outside a normal ./configure go here ########################################################################

I think the files in usr/doc/gtkperf are generated by the application itself, while the SlackBuild generates usr/doc/gtkperf-0.4.0You can delete the first dir or just move the files to usr/doc/gtkperf-0.4.0

I can see what happens: the usr/doc/gtkperf-0.4.0 dir is created by the slackbuild. And I totally agree it would be good to have that usr/doc/ dir rather than a usr/doc/ dir simply called "gtkperf"...

But how would I be able to delete the "simple" dir created by the ./configure script of the app? It is only created once I install the package?

I could simply comment out the mkdir commands, etc. in the SlackBuild for the gtkperf-0.4.0 dir, but then we'd be left with the less informative /usr/doc/gtkperf dir...