Page 1 of 2

slkbuild (formerly buildpkg) features

Posted: 8. Jun 2009, 22:43
by thenktor
So far we agree that an easy to use build system is needed. This probably will be buildpkg or some fork of it. Many systems are using such systems, so feel free to suggest other systems, that can be used for a Slack based distribution.

This is a list, what I think buildpkg is missing (more things to come):
- package format should be chosable (tgz, txz, tbz) *FIXED*

EDIT:
The tool now is called slkbuild ;)

Re: buildpkg features

Posted: 9. Jun 2009, 07:25
by gapan
I actually think we should remove things from buildpkg. :D

Everything that has to do with dependencies to get started... :mrgreen:

Re: buildpkg features

Posted: 9. Jun 2009, 10:48
by thenktor
gapan wrote:I actually think we should remove things from buildpkg. :D
Yes, perhaps there is some bloated stuff.
gapan wrote:Everything that has to do with dependencies to get started... :mrgreen:
Why? It should use depfinder and with extradepends and lessdepends it's a clean solution in my opinion :)

Re: buildpkg features

Posted: 9. Jun 2009, 10:59
by gapan
Well, I don't think dependencies should be a part of building a package. When someone wants to build a package for his own use, or for testing, he doesn't care at all about dependencies. It only matters when putting packages in the repo, and that 's only for the first time too. When building a new version, most of the times dependencies stay exactly the same, so no reason to calculate them (and update dep files) over and over again. There are a lot of times when you have to edit the dep file manually anyway and autocalculation of dep files brings the illusion that you have nothing else to do about them. And look at the number of options that were put in buildpkg just to be able to handle them: extradepends, lessdepends, norequiredbuilder, keepdepfile. Using depfinder when you really want to calculate dependencies is much simpler IMO than having to deal with all that clutter.

Re: buildpkg features

Posted: 9. Jun 2009, 11:35
by thenktor
OK, then let's do like this:
If building for the first time (no existing dep file) buildpkg should run depfinder. This dep file can be tweaked manually afterwards. And if there is an existing depfile of an older version, buildpkg should just use this one (afaik this is what the keepdepfile option is doing).

This way makes sure that there always is an dep file and all depfile options in buildpkg can be stripped.

Re: buildpkg features

Posted: 9. Jun 2009, 11:53
by gapan
That's just another step of automation/complexity for me. What if the dep file isn't stored locally and it's in the repos? Maybe all I would want to do is rebuild the package for my own use, with a couple of more configure options enabled/disabled. Why should dependencies be calculated for that?

And what if you already have a dep file, but you want to create a new one, because of an added/removed configure option that would change the dep file?

Isn't running depfinder on a package easy enough for when you want to actually do it?

Keeping it simple is always the best choice I think,

Re: buildpkg features

Posted: 9. Jun 2009, 12:21
by JRD
With the latest explanations, I agree with Gapan : just drop all options and creation of dep files with buildpkg.
If we need a new dep file : depfinder's ok. We don't need new dep file ? ok so nothing to do.

Re: buildpkg features

Posted: 9. Jun 2009, 12:58
by thenktor
But I don't want to rename my dep files manually everytime i build a new package :mrgreen: Why not keep the 'keepdepfile' feature?

Re: buildpkg features

Posted: 9. Jun 2009, 13:36
by JRD
hummm good point. I don't have the answer.

Re: buildpkg features

Posted: 9. Jun 2009, 15:29
by gapan
thenktor wrote:But I don't want to rename my dep files manually everytime i build a new package :mrgreen: Why not keep the 'keepdepfile' feature?
You don't have to. Just don't provide a new dep file with the new version and the renaming will happen "on the fly" in the repository. metagen.sh does that already.