Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#13905 - [awesome] .in files in package

Attached to Project: Community Packages
Opened by Damjan Georgievski (damjan) - Saturday, 21 March 2009, 18:48 GMT
Last edited by Ronald van Haren (pressh) - Thursday, 04 June 2009, 11:26 GMT
Task Type Bug Report
Category
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The awesome package contains .in file like for ex:
awesome /usr/share/awesome/lib/awful/client.lua
awesome /usr/share/awesome/lib/awful/client.lua.in

the .in files are used in the build system and are templates for the actual .lua files that are used. As such they are totally unneeded in /usr/share. I don't know if this is a bug with the Arch package or upstream.


Additional info:
Repository : community
Name : awesome
Version : 3.2-1


This task depends upon

Closed by  Ronald van Haren (pressh)
Thursday, 04 June 2009, 11:26 GMT
Reason for closing:  Implemented
Additional comments about closing:  awesome 3.3-1
Comment by Ronald van Haren (pressh) - Sunday, 29 March 2009, 19:22 GMT
If those .in files are useless it seems upstream to me. We just build with "-DCMAKE_BUILD_TYPE=RELEASE". I don't really feel like removing those files manually to save a few kb of space. You may want to ask upstream why they install those files by default.
Comment by Damjan Georgievski (damjan) - Thursday, 14 May 2009, 12:06 GMT
  • Field changed: Percent Complete (100% → 0%)
How much specific can I be in this small text-area? The bug was improperly closed anyway since it didn't solve the issue.
Also .. my specifics would be lost where noone can see them.

Do you thinkg I'm doning this to annoy you?!? Or to make Arch's packages better? C'mon.

The problem is that the Arch package didn't properly build Awesome in the first place, but awesome also didn't make it easy to be properly built. I've suggested a patch to the awesome project and it was implemented, now the PKGBUILD in Arch needs to be changed.
Comment by Jan de Groot (JGC) - Thursday, 14 May 2009, 12:06 GMT
Including useless files in a package is a packaging bug, even if upstream ships them by default that way.
Comment by Ronald van Haren (pressh) - Thursday, 14 May 2009, 12:18 GMT
please provide a link to the upstream bug report where is is fixed as you say
Comment by Damjan Georgievski (damjan) - Thursday, 14 May 2009, 12:20 GMT
Thanks for reopening,
a little context: the build system of Awesome was desinged so that it's built in a separate "build" directory. That's what just "make" in the root of the source directory would do.

Invoking "cmake ..." in the root of the source directory would overwrite the original Makefile, and break this. But there was no easy way to specify install PREFIX and other cmake parameters otherwise.

But now, in at least 3.3-rc2, awesome already has a patch that makes it very easy, the PKGBUILD will need to something like this:
build () {
cd ${srcdir}/${pkgname}-${pkgver}
make CMAKE_ARGS=" -DPREFIX=/usr -DSYSCONFDIR=/etc -DCMAKE_BUILD_TYPE=RELEASE" || return 1
make DESTDIR=${pkgdir} install || return 1
...


so, no explicit invocation of "cmake" is needed.
Comment by Ronald van Haren (pressh) - Thursday, 14 May 2009, 12:41 GMT
okay thanks. I'll implement it like that when 3.3 comes out (should be in a few days I suppose). It doesn't work on the svn snapshot we currently have in community (it just puts everything in /usr/local) and I don't want to risk another config syntax change between rc2 and final.
Comment by Damjan Georgievski (damjan) - Thursday, 14 May 2009, 12:53 GMT

Loading...