Package builder utility

[M0E-lnx]

that would save  the effort and time to go and download the sources,it will also greatly improve the time for mass compiling.
 

sinp is very cool. I just write

Code: [Select]

sinp basket and it downloads,compiles,packages and installs it.
One downfall is that its source library is kind of poor (slackbuilds for sw12) and outdated (wine was old,among alot of other things and it lacked quite a bit of basic sources)

This is exactly why I chose to build this application as it is now, because that way, you dont have to worry about repos being updated... if there is new source code out there, run vpackager, point, click, package, and install...

the scripts thing might be a good addition... but I dont like to depend that much on others to keep the script list clean and tidy.

[blurymind]

thats why i proposed vec to have its own buidscript repo,where to put all the build scripts:
*static (stable)
and
*dynamic (latest from cvs)

Going mainstream with this idea will make a slacker weep of happiness 

I agree that depending on buildscripts.org is not all that glorious,plus they dont use vec's default configure and checkinstall options (generating tgz instead of tlz)
So what it should do is simple,but how simple is it to achieve in gambas?

search for buildscript(s) -----> show all avaiable versions of buildscripts for package ( to build version x.xx ,x.xb or cvs of source ) --->pick one---> wget and innitiate the script --> compile --> question: save package / install package /edit package (whatever is chosen,package is saved to tmp)
the build script repo can have the written slackdesc,icon,desktop files...

So if sinp can do it,we can do it better.It will take time to collect build scripts for everything,but from the start i think that it is a good idea to have one for each package at the repo. One might need to fetch a newer source of something to build something...this will also save everybody the fuss of searching for a source file over and over again..
Having a search feature to vpackager would not only motivate everybody to submit such scripts,it will also make vector linux more interesting. Maybe other slack-based distros will want to have vpackager with such features, but what is VL's buildscript repo,will remain vl's buildscript repo.

[M0E-lnx]

This might be hard to pull off... The main problem here is that not all scripts are written in the same manner. Most slackbuilds do not wget their own source, you need to privide it. There is no way of telling which version of a program the slackbuild is written for by just looking at the name, you have to crack it open and find the value of $VERSION.
Needless to say, All slackbuilds might need a bit of tweaking to generate the desired results. Also, the user customization may not be available at all. At first glance, this is what you're saying this gambas program should do

Find a script
  |_ Either locate the source or edit the slackbuild to make it wget it's own source
Run the script
Prompt whether to install or save the package.

That might be kind of hard to control

[blurymind]

there must be a nice and simple manner to pull this off.
Too much power is hard to control. Only the basics are good too.

I sepparated the slackbuilds into two types:
static
and dynamic
the dynamic ones would fetch the source from cvs (download the source themselves via svn,git,cvs...) (they should use different variables,or slightly different set of variables)

the static ones could be the standart slackbuilds and every source package could have its own slackbuild..

maybe there is a better way to achieve it.

[M0E-lnx]

but the static scripts woul get outdated really quick though. That is my main concern. Most of the time this scripts will work when you modify it to build the newer version and naked minor adjustments such as patching. This is what is difficult to do and control. This is also the downside to this idea. This would inevitably make the application to depend on someone to keep the scripts up to date. i'm not sure we want a whole other type of repository or have the time or manpower to keep up with all of it

[blurymind]

but the static scripts woul get outdated really quick though. That is my main concern. Most of the time this scripts will work when you modify it to build the newer version and naked minor adjustments such as patching. This is what is difficult to do and control. This is also the downside to this idea. This would inevitably make the application to depend on someone to keep the scripts up to date. i'm not sure we want a whole other type of repository or have the time or manpower to keep up with all of it

all slackbuilds which have $VERSION variable,which the user can set,and that variable is included in another SRCURL variable,which it uses to get the source in the following matter:

Code: [Select]

SOURCE="SRCDIR/${PRGNAM}-${VERSION}.tar.bz2"
SRCURL="http://dl.sourcefogre.net/<appname>/${PRGNAM}-${VERSION}.tar.bz2" that variable can be used to get the ssource from somewhere

http://alienbase.nl/slackware/slackbuilds/wxGTK/build/wxGTK.SlackBuild

thats pretty beautifully executing the operation,leaving the user only with the need to define the version of the source ($VERSION),before executing the script...but it leaves the question, how would the user know what avaiable version is there (the latest stable one)... I'd say the way sourceforge handles urls can work.I remember seeing a url for a link to SF that ended with "...downloadlatest" or something like that..butit was for browsers.. well,this one way would work too,right?

well,the user will atleast decide... from one script,and you wont have to update it

[M0E-lnx]

but that's exactly what i'm saying. Even when the user knows enough to modify a slack build i do not see the point in writing a graphical front end to a slack build. My point here is if you can edit the script you might as well just execute it while you're at it. there is not much more to do at that point anymore. vpackager is designed to build just about any source by automating the common build procedure. It is not hard coded to build just one version of one application.

[blurymind]

well,a graphical frontend to search and download the buildscript would be great...my main point is the buildscript repository and specially buildscripts for live source (git,cvs,svn)
wouldnt that be great to have

if its hard or impossible,lets at least have a library for such scripts somewhere.They are very handy.

[easuter]

Blurymind, if you want a slackbuild collection, then you may be interested in DarkVision's SlackBot script collection. It even has an ncurses frontend: http://www.mkanet.de/data/slackbot/0.6_saturn/index.html

Though I don't recommend you use this to build packages for the repo, since there is a lot of Slackware-specific stuff, especially when it comes to init-scripts and package descriptions, but it will give you an idea of what it is you are requesting Moe to do.

This kind of script collection is probably almost a full-time job to maintain, and is *never* complete, since new versions of apps are always coming out, project hosting changes, and distro-specific changes occur.

But turning vpackager into a Slackbuild frontend really creates constraints (that Moe has already explained). Not only will the bash scripts have to be maintained, but the vpackager gambas code might also have to be changed every time a significant modification is made to the Slackbuilds. Its really a lot simpler to maintain *one* codebase that will do everything.
For this, I suggest that you actually take a look at the vpackager svn branches and see what development is taking place there (Cmake, python support, among other things). And it might give you a better perspective of the development work that is already being put into this project (and the coding it takes to make these features possible)....who knows maybe you could help with the coding too

[blurymind]

ok,scratch the idea about vpackager's module to get buildscripts... how about having our own repository for vl buildscripts (configure&make options,tlz...) and a way to browse/search through them (even if with google) ..maybe vpackager aint ready to handle build scripts (slackbuilds) but having a repo for svn,cvs,git...ah,its such a dream.

ok,i dont wanna be a nag,it was just a suggestion. 

[M0E-lnx]

Let's lock this thread, and discuss the new vpackager in a new thread here:
http://www.vectorlinux.com/forum2/index.php?topic=4259.0