FS#13403 - Introducing 'variants' in makepkg
Attached to Project:
Pacman
Opened by Denis Martinez (denis) - Saturday, 21 February 2009, 13:38 GMT
Last edited by Allan McRae (Allan) - Wednesday, 04 March 2009, 23:27 GMT
Opened by Denis Martinez (denis) - Saturday, 21 February 2009, 13:38 GMT
Last edited by Allan McRae (Allan) - Wednesday, 04 March 2009, 23:27 GMT
|
Details
This idea is to introduce some new variables in the
PKGBUILDs :
- variant_name: name of the variation of an existing package (which could be an official/aur package) - variant_scm: kind of source code management (could be "", git, cvs, svn, ...) - pkgname: just the name of the original package The resulting pkgname would then be determined in the following way: - First we try ${pkgname}-${variant_name}-${variant_scm}, - then ${pkgname}-${variant_scm} - then ${pkgname} So, it would be possible to replace: pkgname="kernel26-zen-git" with: pkgname="kernel26" variant_name="zen" variant_scm="git" Advantages: - It doesn't hurt the current packages (if the variables are left empty). - It can greatly help to reduce the mess in AUR. for example: all the kernels and modules, font-related packages, or compiz (especially during the early beryl/XGL days) A modification in AUR could make it possible to group all available variants under a single package. - It may ease package management by providing automatic 'replaces' and 'provides'. I'm not sure though if it is a good idea. |
This task depends upon
Closed by Allan McRae (Allan)
Wednesday, 04 March 2009, 23:27 GMT
Reason for closing: Won't implement
Additional comments about closing: See comments
Wednesday, 04 March 2009, 23:27 GMT
Reason for closing: Won't implement
Additional comments about closing: See comments
The only "gain" I can see from this is that it is easy to group packages in the AUR. But packages are already listed by name and thus grouped. And we loose the ability to just take the value of pkgname and find out what is being built. This gets a -1 from me.
There is more behind this idea than just grouping packages. I think the AUR mess is a real problem, and keeping the packagement the way it is is not going to help. And it's your brain that does the sorting, not the algorithm.
Also when a user submits a package to AUR, and I want to suggest a change or an updated version
- I try to contact the maintainer maybe he will accept my contribution
- If not, my only option is to create another entry
The difference here is that you upload your variant under the original package. The original is unchanged, and you don't need permissions to do it. Everyone benefits.
- we loose the ability to just take the value of pkgname and find out what is being built.
If I understand you're saying that backwards compatibility is lost, which is right.
But it can still be obtained by writing something like
basepkgname="kernel26"
variant_name="zen"
variant_scm="git"
pkgname=$basepkgname${variant_name:+-${variant_name}}${variant_scm:+-${variant_scm}}
- I'm not sure what split packages are, I suppose it's something like the kdemod build system
The problem is that if you group everything in the same PKGBUILD, which has a single maintainer in AUR,
the other users don't have the right to edit.
I like my idea because it makes contribution easier.
_basepkgname="kernel26"
_variant_name="zen"
_variant_scm="git"
pkgname=$_basepkgname${_variant_name:+-${_variant_name}}${_variant_scm:+-${_variant_scm}}
should just work. So this is not something that needs supported in makepkg. Maybe the AUR could have some knowledge of a set of custom variables. But that would need a feature request to the AUR project.
However omitting underscores was intentional, in order to make the feature somewhat standard.
If the feature exists but is not visible, it is possible that nobody would want to use it.
Moreover, should custom variables be used for something else that there were designed ? (reserved to the user)
This way there's no real need to muck up a PKGBUILD with this meta-info that's not needed by the underlying system (neither pacman nor makepkg should care about this info).