The New vpackager Thread - take a peak

[saulgoode]

One of the things I really appreciate about Slackware (and thusly Vector) is that, with very few exceptions, the packages are built from source code which is unmodified from that available from the originating project's homepages. This minimizes risk of errors creeping into a package and eases the task of customizing a project to my own needs. Better still, it allows me to readily contribute back to a project or otherwise participate in its development.

Randomly scanning through some of the "packages" (actually just scripts) in the Crux repositories, I see that many of them follow this same practice (of obtaining source directly from the project). However, I do not see a ready way to determine if or when this is the case (I had to manually compare the sources specified in the scripts with the projects' source locations); and determining what modifications might have been made to the source if it is from a different location.

So, my first concern is about how this "chain of custody" of package source is to be addressed.

In addition, Crux packaging guidelines seem to specify three practices that are at odds with guidelines of Slackware (and, to my knowledge, Vector):

• Stripping documentation files from the package
• Disabling language support (NLS)
• Separating related programs into multiple packages

It appears that the only benefits of incorporating Crux ports packaging into Vector would be the catalog of available Crux scripts and the fact that a packager doesn't have to search for a project's homepage for source. It seems to me, the first benefit would be better covered by implementation of a repository of Vector-Build scripts (something which would probably be necessary anyway, owing to the differing guidelines between Crux and Vector); and the second benefit is pretty well nullified by the fact that packagers will need to document any disparities between the included sources and those of the originating project (knowledge necessary to the Vectelopers, if not the users).

The NLS problem is easily handled automatically, but for the other concerns, using Crux ports might entail more effort than it saves.

[M0E-lnx]

As far as I know, the cruxports thing here is more like a universal build script that can be controlled by using a function on a file named "Pkgfile".

Here is a sample from the few port scripts I've written to jump start this whole thing... they're located here http://vectorlinux.osuosl.org/veclinux-5.9/ports/

Code:

# Description: GTK+ based IRC client
# URL: http://www.xchat.org/
# Maintainer: M0E-lnx
# Optimized to include support for gettext, and to disable the old
textfe, also added patch
# Depends on: openssl, gtk, perl

name=xchat
version=2.8.4
release=2
source=(http://www.xchat.org/files/source/2.8/$name-$version.tar.bz2
        http://www.xchat.org/files/source/2.8/patches/xc284-scrollbmkdir.diff)

build() {
        cd $name-$version
        patch -p1 -i $SRC/xc284-scrollbmkdir.diff --verbose
        ./configure --prefix=/usr \
                --enable-openssl \
                --enable-perl \
                --enable-ipv6 \
                --disable-gnome \
                --enable-gtkfe \
                --disable-textfe \
                --disable-python \
                --disable-tcl \
                --with-included-gettext \
                --disable-nls
        make
        make DESTDIR=$PKG install
        rm -rf $PKG/usr/{etc,share}
        install -D $name.desktop $PKG/usr/share/applications/$name.desktop
        install -D $name.png $PKG/usr/share/pixmaps/$name.png
}

The enable / disable language support and / or other features are controlled by the build procedure for each application IIRC.
To add to that, IIRC, the cruxports4slack package that we are hosting has been modified to make up-to-vector-standards packages. As you can see from the sample script, it works pretty much like a slackbuild. The build procedure can be fully customized to fit each application. Even the binary stripping can be done and the documentation packaging.

[InTheWoods]

Ahh... that wiki....

This is the third VL related Wiki I've learned of in as many weeks.

Clearly I skimmed over the previous thread on this to quickly. I take it the Google Wiki is for this project only.
I added links in the DokuWiki to the Google Wiki How To's and downloads. That should  take care of things for now.

I also declared you (M0E-lnx) as the author of the vecpackager article in the DokuWiki. 99% of it was relocated material from your vpackager section in How to install software from source code.

Hope you don't mind.

[M0E-lnx]

Not at all. I guess we'll just have to check it every once in a while to make it's up to date. The wiki at the project page will change in the near future as we get it polished up a bit

[blurymind]

Code:

=======> ERROR: Md5sum mismatch found:
MISSING   feecc3ccb4639b672d8446154a4fb700  wine-0.9.45.tar.bz2
NEW       aa729097ddb324185a3e092b37a5f9fe  wine-0.9.46.tar.bz2
=======> ERROR: Building '/usr/ports/opt/wine/wine-0.9.46-i586-1vl59.tlz' failed.
Result: FAILED

can we disable mdsums check? Whenever I edit the build file to match latest version of something, i get to this errer,right after its source is downloaded.

[M0E-lnx]

can we disable mdsums check? Whenever I edit the build file to match latest version of something, i get to this errer,right after its source is downloaded.

Right-click on the port name, select "Check md5sum" it will fix this for you if there is a md5sum mismatch

You can also bypass the md5sum check when you click on "Build selected" a new window comes up showing the package name, and offers you to select which tag to use for the package... There is a "Install after build" checkbox and then there is a "ignore md5sum" checkbox... just check the box, and it will bypass the md5sum test

[saulgoode]

@MOE-lnx

Thanks for the response. I was starting to get the impression that CRUX repositories would be relied upon for Vector packages. For the reasons stated, I think that would eventually cause grief for the Vector developers.

I think a better solution would be for your build script -- rather than doing the compilation -- to locate the appropriate source & SlackBuild (and DL if needed), apply any patches needed (either updates or VL-specific changes), define the appropriate environment variables, and then call the SlackBuild script (as mentioned previously, this is close to the approach taken by DarkVision's SlackPacks).

By using the existing SlackBuild baseline, compatibility with the Slackware base would be encouraged and, in the long run, entail less maintenance effort on the part of Vector's developers.

[M0E-lnx]

I can understand your concern, however, if anyone plans to submit packages built from cruxports, they should modify the Pkgfile to reflect a good slackware-compattible build. This could be done with the GUI from the "Actions" > "Advanced" > "Modify build file" menu

The crux bacend is completely capable of patching if necessary and adjusting anything that may need to be.

At the end of the day, everyone chooses their way of packaing, some prefer typing the commands hemselves, while other like the slackbuild method, and others, like the idea of automating the process as much as possible, and just changing what needs to be changed in the script.

This is what crux does. It is a base script whose build procedure can be shaped in any form one needs to.

I have started working on some VectorLinux scripts myself. Anyone who wants to contribute can look at the samples, and use them as a template to get going. I figure, with this, eventually we can have our very own ports repository that can be very useful, and easy to contribute too.

[blurymind]

awesome. This is exactly the best approach i can think of too.
I would love to submit such scripts for our ports-repo...
I think that having a little tut at the wiki for that would be absolutely neat.
A simple and well put script can be easily edited to fit different applications.

=)  ... not to mention that at our ports repo,we will have our own slack-desc files,which include more info such as application website,author... if possible build date and packager id... being applied to it (or its getting too complicated..). Having more control over the process will make us all feel more comfortable with the ports,and using them.
I am still enthusiastic about the build from svn/cvs/git scripts....

[M0E-lnx]

If you want to contribute to the ports repo, make a directory called "ports" in your vectorcontrib account, and let me know, I'll add them to the repos

[Dweeberkitty]

Hey MOE-lnx,
Is it possible that your program (looking very sweet BTW) could write SlackBuilds or some similar script? I guess this would be called a feature request. 

I'd like to have Vpackager write the scripts automatically, or on demand, so one doesn't have to write the scripts manually. Keep up the good work!

[M0E-lnx]

That is absolutely possible... I'll start working on it As soon as I get a chance

_EDIT_
BTW, I just released RC2.
The GUI looks a lot better, and the cruxports4slack has a lot more features...

Please upgrade now

[Dweeberkitty]

_EDIT_
BTW, I just released RC2.
The GUI looks a lot better, and the cruxports4slack has a lot more features...

Please upgrade now

I had just downloaded it when I posted. It looks great!

[Dweeberkitty]

Hey MOE-lnx!

You've already got Python and Cmake support. How much more would it take for you to implement Scons support? That would help with a lot of applications that unfortunately use the scons system instead of a standard Make or Cmake.

Your app is great! Keep it up. I love it.

[M0E-lnx]

scons can be done and it's in the plans for the near future. However the current cmake support still needs lots of testing. I'd like to get you all to test that and get all the bugs in that area worked out before adding support for scons. I tested the python support myself and it seemed ok but i also need others to test. Specially now because i don't have as much time to spare for this project so i'll be relying a lot more on bug reports to get it done