dear,
"gnashley
Amigo developer"

i was planing to post this one for a long time.

what about combining src2pkg +slack.build +swaret/slaptget
for making slackware packages?? and install

(something similar to emerge in gentoo)

we can also use gentoo portage for fetching the sources

earlier i found that the swaret developer was looking for a new maintainer/developer, as he is going for someother project with fedora or something like that.. and he wanted someone who is proficient in perl.

why dont u combine swaret along with your project, so that
"src2pkg firefox --rebuild" means - it will fetch firefox source and use src2pkg to build package, and for fetching sources we can use swaret.
suppose someone want to use slack.build to use for compiling we can add that as a possibility.
----------
a separate question
right now, can i use slack.build use as a config file for src2pkg?
-----------------

right now we have 1. src2pkg, 2. swaret,, (may be slack.builds to compiling options) 3. gentoo source repositories

so my question is
1, is it possible to use src2pkg act like an emerge utility?
( i know that it is a painfull job, but still, any posibility ?)
apart from usual package making

regards rkrishna

That just looks plain nasty ...

Agreed. If you want to walk on that path, maybe you should start thinking about switching to Ubuntu instead.

Eric

I don't think combining these would be a good idea, either. It would be better to use a project intended for something like that from the ground up like the emerde project, which is basically a port of portage to Slackware.

Chess is currently developing software called something like sbo_pkg that will help you sync to the SlackBuilds tree, build, and install packages. Check out the SlackBuilds mailing list for more info on that.

Also, if you distro hop for something like this check out Arch Linux and not Ubuntu- unless you really want something like Ubuntu.

Nope, install the way that it was intended. KISS method...............

Ubuntu......****shudder*****

I like my Slackware PV style.

I can picture gnashley working over this software like Gene Wilder in Young Frankenstein. As it compiles there is a flash of lightning and gnashley cries out: 'I give my creature ..... life!'

Andrew

these days i had to compile few packages, i used both slackbuild and src2pkg, since it is slackware nothing fancy will ship with slack. but we can have choices

earlier slackpkg was there now it is removed and for getting slack.builds we have to search a lot.

SqdnGuns: KISS - dont have pkgbuilder, (earlier we had slackpkg)


shadowsnipes:
at least this information is good. but i couldnt find any info named sbo_pkg but i am looking forward to that
regards to all

Why do you say "we don't have slackpkg"?

From the Current (pre-release) ChangeLog for Intel:
Piter Punk is still keeping it up-to-date, and it's still in Slackware.

here i got something new for me

simplepkg
http://slack.sarava.org/node/15
from their page: 17 Building packages

Bruce Hill: probably i may be wrong, anyway my installations dvd didnt had slackpkg, usually it resides in /extra, this was one of my first installation packages

You must have just missed it, because it's in Slackware-12.0,
and it's in -current, also.

How did I miss seeing this 'juicy' topic yesterday?

First of all, let me deal with the idea of incorporating swaret or any other package *management* functionality. This is completely different from package *creation* and so goes way beyond the scope of src2pkg. Frankly I am not interested in even using package management software -maybe if I were running debian. The system must be designed from the ground up to do pkg-mgmnt successfully and requires lots of human-generated data -without an adequate database you'll alway have failures. Debian is the only distro that has come even close to perfection in this area -and I have no pretensions of coming close to matching the success of more than one thousand eager volunteers!

Now, about using other build scripts. I have put a lot of thought into this one and even incorporated limited functionality which 'leverages' config options found in rpm *.spec files or debian 'rules' when they are found in the sources. This feature is far from perfect since it requires parsing the options out of the files and the options do not have a consistent syntax between debian 'compat' levels or rpm versions. Still, it is quite usable and helps out sometimes -even if only to generate a nice slack-desc file without any typing.

I have thought a lot about having src2pkg be able to use SlackBuild scripts and possibly to search for and download them when one is available for the package you want to build. I was very pleased to see about the sbo_pkg program just a couple of weeks ago -it does about what I had in mind -except that I wanted to be able to just create(and update) a *listing* of the available SlackBuilds instead of making you download the complete builds archives. You'll pleased to hear that src2pkg could very easily use your SlackBuild files instead of its' own *.src2pkg files. Adding the real functionality in a non-hackish way will only take a few lines of code, but actually, I think it will already do it just by changing the name of the SlackBuild to $NAME.src2pkg and using 'src2pkg -X' to execute it. This won't give you acces to all of the handy features of src2pkg for SlackBuilds, but as I said, it's not gonna take much to integrate the functionality more fully.

As an extension of reading info from 'rules' and *.spec files, I've looked at using conf files from still other build systems -including gentoo, BSD's pkgsrc, connary, etc. The gentoo system is way to complex to justify -it would take too much code to parse out the info to make it worthwhile. pkgsrc is also quite different. What I did find that is easy to make work is the crux ports system. There is also a derivative for deli linux which uses the same conf file syntax. And the conf files are quite similar to those from the slackbuilds system from linuxpackages.net. the ports database from crux contains a couple of thousand scripts so it makes a valuable contribution to the human element needed. I've discussed the inclusion of compatibility with such ports systems with a couple of my most avid users and contributors. I do expect to be adding this feature before too long -perhaps as a separate 'wrapper' for simplicity. I have already made this work in a quick test here at home. Again, it only took a few modified lines to get the basic functionality working. But I have put off integrating this functionality for a while longer as I am trying to get the existing features debugged as fully as possible for a really, really stable and reliable release of src2pkg which I *might* propose for inclusion in an official Slackware release.

For now, it looks to me that sbo_pkg may be working quite well for handling SlackBuilds. For easy, lightweight access to a 'ports' type system -look around for 'crux4slack' -I just noticed that Vector Linux may be using it -although it is originally a crux ports system modified for use with deli-linux. If I don't integrate the functionality into src2pkg itself, I'll probably be doing some refinements to the program and releasing it for use alongside src2pkg.

rkrishna, keep your ideas and feedback coming as it has always been helpful. You are not alone in wishing for portage compatibility -I have one very avid user who contantly begs me to go in that direction -and add a GUI on the way...
Meanwhile, src2pkg is still the only sofwtare-builder which can work (usually) with no conf file at all or write one for you if you want it. For a long time I've kept in mind the possibility of having src2pkg write real SlackBuilds for you, and this may be coming up fairly soon. Since src2pkg 'discovers' a lot of info about the sources it is not gonna be all that difficult to make it write SlackBuilds instead of src2pkg scripts -although this won't work for all sources it will for the great majority.
Remeber this: One of the main reasons for the success of src2pkg is that I always remind myself what the original scope of the program is -create *one* good package. There are already many ways to easily extend this (like building groups of dependent packages, e.g GNOME, X). But this is left to small scripts which drive or control src2pkg while leaving it to do its' 'one good package' job. In fact, even the src2pkg 'program' is just such a wrapper -the real package-building work is done by the functions which were originally only usable by running a src2pkg script.

Quote andrew.46: "Gene Wilder in Young Frankenstein"
Now how did you know I look exactly like that?

Check out the link in my signature for the google code site for sbopkg. I just released version 0.0.6. :-)

yes that will be fine.

when i compiled packages using src2pkg, slack.builds, i was really got confused,
src2pkg is handy just do "src2pkg source" it will create a package, but

the other one which is explicitly meant for "individual packages", may have more configure options, but the problem is, how to get it. we have to search the site and download it, so i searched weather there is any utility which will fetch slack.builds automatically, of course this utility is not outside kiss principle,

also i checked whether, our src2pkg can make use of slackbuilds scripts so that the packages will be more perfect, suits our slack the best

so naturally i will ask, why not combine all of these. i thought i can ask gnashley itself, more feed back from lq users, and know more options if available

anyway "sbopkg" is a new stuff