AuthorTopic: The New vpackager Thread - take a peak (Read 44335 times)

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.

« Last Edit: September 27, 2007, 10:04:26 am by saulgoode »

Logged

A complex system that works is invariably found to have evolved from a simple system that works.

# 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

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.

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.

=======> ERROR: Md5sum mismatch found:MISSING feecc3ccb4639b672d8446154a4fb700 wine-0.9.45.tar.bz2NEW 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.

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

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.

« Last Edit: September 30, 2007, 12:27:31 pm by saulgoode »

Logged

A complex system that works is invariably found to have evolved from a simple system that works.

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.

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....

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.

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