slkbuild (formerly buildpkg) features

Old stuff that should not bother anyone anymore
User avatar
thenktor
Salix Wizard
Posts: 2426
Joined: 6. Jun 2009, 14:47
Location: Franconia
Contact:

slkbuild (formerly buildpkg) features

Post by thenktor » 8. Jun 2009, 22:43

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 ;)
Image
burnCDDA (burns audio CDs)
geBIERt (German beer blog)

User avatar
gapan
Salix Wizard
Posts: 5538
Joined: 6. Jun 2009, 17:40

Re: buildpkg features

Post by gapan » 9. Jun 2009, 07:25

I actually think we should remove things from buildpkg. :D

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

User avatar
thenktor
Salix Wizard
Posts: 2426
Joined: 6. Jun 2009, 14:47
Location: Franconia
Contact:

Re: buildpkg features

Post by thenktor » 9. Jun 2009, 10:48

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 :)
Image
burnCDDA (burns audio CDs)
geBIERt (German beer blog)

User avatar
gapan
Salix Wizard
Posts: 5538
Joined: 6. Jun 2009, 17:40

Re: buildpkg features

Post by gapan » 9. Jun 2009, 10:59

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

User avatar
thenktor
Salix Wizard
Posts: 2426
Joined: 6. Jun 2009, 14:47
Location: Franconia
Contact:

Re: buildpkg features

Post by thenktor » 9. Jun 2009, 11:35

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.
Image
burnCDDA (burns audio CDs)
geBIERt (German beer blog)

User avatar
gapan
Salix Wizard
Posts: 5538
Joined: 6. Jun 2009, 17:40

Re: buildpkg features

Post by gapan » 9. Jun 2009, 11:53

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,
Image
Image

User avatar
JRD
Salix Warrior
Posts: 949
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: buildpkg features

Post by JRD » 9. Jun 2009, 12:21

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

User avatar
thenktor
Salix Wizard
Posts: 2426
Joined: 6. Jun 2009, 14:47
Location: Franconia
Contact:

Re: buildpkg features

Post by thenktor » 9. Jun 2009, 12:58

But I don't want to rename my dep files manually everytime i build a new package :mrgreen: Why not keep the 'keepdepfile' feature?
Image
burnCDDA (burns audio CDs)
geBIERt (German beer blog)

User avatar
JRD
Salix Warrior
Posts: 949
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: buildpkg features

Post by JRD » 9. Jun 2009, 13:36

hummm good point. I don't have the answer.
Image

User avatar
gapan
Salix Wizard
Posts: 5538
Joined: 6. Jun 2009, 17:40

Re: buildpkg features

Post by gapan » 9. Jun 2009, 15:29

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

Locked