[pacman-dev] FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package

Jan Mette jan.mette at berlin.de
Tue Jun 17 08:07:37 EDT 2008

Am Montag 16 Juni 2008 16:35:33 schrieb Allan McRae:
> I have been thinking about this some more and my head is beginning to
> hurt...
> > +		backup_o=$backup
> > +		conflicts_o=$conflicts
> > +		depends_o=$depends
> > +		groups_o=$groups
> > +		install_o=$install
> > +		license_o=$license
> > +		pkgdesc_o=$pkgdesc
> > +		pkgname_o=$pkgname
> > +		pkgver_o=$pkgver
> > +		provides_o=$provides
> > +		replaces_o=$replaces
> > +		url_o=$url
> Why would we need to change license, pkgver and url?  This is for
> splitting packages that come in a single source file...  

Just one example: GTK-KDE4 (check kde-look.org) consists of two tarballs
on different sources, with different licences... (The gtk part is GPL, the qt4
part seems to have no proper license yet)...

However, we dont split this package (yet), i just wanted to come up with an

> Otherwise you
> make two PKGBUILDs. Can anyone give me a possible reason for changing
> these.  I'm not sure about groups but there might be some reason to
> change that.  I can think of reasons to change the options array so that
> should be included.  Should we allow varying pkgrels between the split
> packages?

Another example: Our kdebase-workspace package is split into 3 pkgs:
kdebase-workspace (binaries), kdebase-workspace-docs and 
kdebase-workspace-icons... When we rebuild this package, we just bump 
the kdebase-workspace pkg, but not the two with docs and icons... So, for
us, there is definitely a need to vary pkgrels between the split pkgs...

> I really think we need to take a big step back here.  What we really
> need is to have a prototype PKGBUILD for a split package that is
> relatively agreed upon.  As I said in other emails there are multiple
> ways to do this and one needs to be chosen.  Once the decisions have
> been made about the approach to take, and a naming scheme for
> functions/variables, then we can look at patches.  At the moment the
> patches seem without a defined goal (at least to me).

Check this one as a "real world" prototype:


(Ignore the SPLITBUILD stuff, just a small change to distiguish them better)



More information about the pacman-dev mailing list