splitpkg consistant with Keep It Simple?

f4hy · 2010-04-19 18:30:37

One of my favorite aspects of Arch is that the PKGBUILDS are simple and I can repackage my own versions of anything I want. I love using abs and hacking away at some PKGBUILD. However recently a few packages have started building more than one package from one PKGBUILD and this makes it very confusing and difficult for me to roll out custom packages. The two I know of so far are the kernel and gvim, and this makes me think this is the future of PKGBUILDs.

I am sure doing this method makes thing easier on maintainers. I can only assume that is why it is being done. However if I want to alter kernel26 to make a custom kernel, previously all I had to do was change the pkgname in the file and it would build a totally independent package. Now this doesn't work. Now you have to change the pkgname of three different packages and change EACH of the build functions e.g. package_kernel26() -> package_kernel26-custom()

Am I the only one confused by these splitpkgs? Am I doing something dreadfully stupid? Could someone explain to me what advantage we gain over all these multipackage per PKGBUILD is?

ataraxia · 2010-04-19 20:19:04

I think you are basically right - it isn't strictly consistent with KISS, and it does exist to make packagers' jobs easier. The biggest advantage appears to be only having to compile something once, even if you want to build several packages from it.

If Arch's definition of "simple" were the same as that of, say, suckless.org, this would probably not have been implemented. I've considering objecting to it before, but:
- it's not really our business, since we're not the devs and it's not our software
- nothing good will come of it, what's done is done
- this will probably go to TGN very soon now anyway

tomk · 2010-04-19 21:00:24

f4hy - this doesn't help you now, but the right time to raise your concerns would have been when the devs were discussing and planning the change - you could have participated in the discussion on the pacman-dev ML.

You can always retrieve old PKGBUILDS i.e. pre-splitpkg ones from SVN and use those as the basis of your customised packages.

Allan · 2010-04-19 21:57:05

f4hy wrote:

Now you have to change the pkgname of three different packages and change EACH of the build functions e.g. package_kernel26() -> package_kernel26-custom()

Seriously... I think any packaging system where only have to make a small number of changes to build yourself a custom kernel is quite simple.

Daenyth · 2010-04-19 22:00:23

It could even be changed to define the function as package_${pkgname[0]} through N, since bash has lazy evaluation... It would all work the same, just be less readable.

eldragon · 2010-04-19 22:02:31

Allan wrote:

f4hy wrote:
Now you have to change the pkgname of three different packages and change EACH of the build functions e.g. package_kernel26() -> package_kernel26-custom()
Seriously... I think any packaging system where only have to make a small number of changes to build yourself a custom kernel is quite simple.

simple is so relative

i agree it was simpler for us the unexperienced. but then, the idea behind the multiple packages within a PKGBUILD is that they use the same source code? is this corect? through that perspective, its simpler to have multiple packages from one PKGBUILD.

one feature that i heard was comming is the hability to tell makepkg which packages to build, that would make things even easier. just edit what you need and bam...you get the best from both worlds...

and no, no patches from me...

some-guy94 · 2010-04-19 22:06:45

eldragon wrote:

i agree it was simpler for us the unexperienced. but then, the idea behind the multiple packages within a PKGBUILD is that they use the same source code? is this corect? through that perspective, its simpler to have multiple packages from one PKGBUILD.

I don't think so, I think it is for building the source once, and making more than one package from it.

Allan · 2010-04-19 22:07:57

eldragon wrote:

i agree it was simpler for us the unexperienced. but then, the idea behind the multiple packages within a PKGBUILD is that they use the same source code? is this corect? through that perspective, its simpler to have multiple packages from one PKGBUILD.

Correct. It is a choice between one PKGBUILD creating multiple packages and multiple PKGBUILDs all using the same build step.

eldragon wrote:

one feature that i heard was comming is the hability to tell makepkg which packages to build, that would make things even easier. just edit what you need and bam...you get the best from both worlds...

Yes: makepkg-git --pkg "pkg1 pkg3"

eldragon · 2010-04-19 22:12:51

Allan wrote:

Yes: makepkg-git --pkg "pkg1 pkg3"

so this means the feature is around the corner

f4hy · 2010-04-20 19:01:08

tomk wrote:

f4hy - this doesn't help you now, but the right time to raise your concerns would have been when the devs were discussing and planning the change - you could have participated in the discussion on the pacman-dev ML.
You can always retrieve old PKGBUILDS i.e. pre-splitpkg ones from SVN and use those as the basis of your customised packages.

I previously had no problems with pacman so was not reading pacman-dev. I had no idea a change like this was in the works.

Also, the makepkg --pkg pkg1 idea sounds promising. Thanks all.

Arch Linux

#1 2010-04-19 18:30:37

splitpkg consistant with Keep It Simple?

#2 2010-04-19 20:19:04

Re: splitpkg consistant with Keep It Simple?

#3 2010-04-19 21:00:24

Re: splitpkg consistant with Keep It Simple?

#4 2010-04-19 21:57:05

Re: splitpkg consistant with Keep It Simple?

#5 2010-04-19 22:00:23

Re: splitpkg consistant with Keep It Simple?

#6 2010-04-19 22:02:31

Re: splitpkg consistant with Keep It Simple?

#7 2010-04-19 22:06:45

Re: splitpkg consistant with Keep It Simple?

#8 2010-04-19 22:07:57

Re: splitpkg consistant with Keep It Simple?

#9 2010-04-19 22:12:51

Re: splitpkg consistant with Keep It Simple?

#10 2010-04-20 19:01:08

Re: splitpkg consistant with Keep It Simple?

Board footer