This is the right place to do this in my opinion, that way you have the global defined defaults for every slpit-package.
To move this inside of the loop would kill the posibility to get the fuits from my next comment.
+ create_package
I think this is wrong from the view to build sub-packages out of one compiled tree.
build should be used to only build the sources and prepare everything which would be usefull for all subpackages.
That way we could add a new param to makepkg to bould only a subset of the splitpackages by overriding the contents of the defined var splitinstall.
+ for it in "${splitinstall[@]}" ; do
+ if [ -d "$pkgdir" ]; then
+ msg "Removing existing pkg/ directory..."
+ rm -rf "$pkgdir"
+ fi
+ mkdir -p "$pkgdir"
I like it that way and we can fix the issue spotted by *Allan McRae* (non working repackage param) if we take the way of my prevous comment and allow to rebuild only a subset of the splitpackages.
I think we should add the splitpackage-name to repackage as additional param to makepkg's command line and use that to override the splitinstall value in case we want repackage.
--8<--
thanks,
Marc
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
06-16-2008, 09:05 AM
Silvio Fricke
FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
Hello Friends,
> > I like it that way and we can fix the issue spotted by *Allan McRae* (non working repackage param) if we take the way of my prevous comment and allow to rebuild only a subset of the splitpackages.
> > I think we should add the splitpackage-name to repackage as additional param to makepkg's command line and use that to override the splitinstall value in case we want repackage.
> >
>
> That looks quite weird to me.
Me, too!
> I would prefer having makepkg keeps all split packages in different
> subdirectories, and have the repackage operation repackage all split
> packages.
At home, I have it implemented with pkg_$funcname-dirstructure. When
I'm at home I will send it to this list.
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
06-16-2008, 02:35 PM
Allan McRae
FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
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... 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?
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).
Allan
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
FS#7982 - patch to makepkg to allow PKGBUILDs building more than one package
