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
slkbuild (formerly buildpkg) features
Re: buildpkg features
I actually think we should remove things from buildpkg.
Everything that has to do with dependencies to get started...
Everything that has to do with dependencies to get started...
Re: buildpkg features
Yes, perhaps there is some bloated stuff.gapan wrote:I actually think we should remove things from buildpkg.
Why? It should use depfinder and with extradepends and lessdepends it's a clean solution in my opiniongapan wrote:Everything that has to do with dependencies to get started...
Re: buildpkg features
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
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.
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
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,
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
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.
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
But I don't want to rename my dep files manually everytime i build a new package Why not keep the 'keepdepfile' feature?
Re: buildpkg features
hummm good point. I don't have the answer.
Re: buildpkg features
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.thenktor wrote:But I don't want to rename my dep files manually everytime i build a new package Why not keep the 'keepdepfile' feature?