[aur-general] avoid usage of fakeroot: always use of build() and package() (Was: application as a TU)

hollunder at gmx.at hollunder at gmx.at
Sun Nov 22 05:14:52 EST 2009


On Sun, 22 Nov 2009 20:12:24 +1000
Allan McRae <allan at archlinux.org> wrote:

> hollunder at gmx.at wrote:
> > On Sun, 22 Nov 2009 16:17:36 +1000
> > Allan McRae <allan at archlinux.org> wrote:
> > 
> >> Ray Rashif wrote:
> >>> 2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar>
> >>>
> >>>> Lukáš Jirkovský wrote:
> >>>>> 2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar>:
> >>>>>
> >>>>>> hollunder at gmx.at wrote:
> >>>>>>
> >>>>>>> On Sat, 21 Nov 2009 14:24:58 -0300
> >>>>>>> Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Andrea Scarpino wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Why do you use package() function when the package isn't a
> >>>>>>>>> splitted package?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Hello :)
> >>>>>>>>
> >>>>>>>> Using both build() and package() is not necessary condition
> >>>>>>>> for use only with splitted packages, its avoid to use the
> >>>>>>>> fakeroot on building process that is not needed in 99% of
> >>>>>>>> packages.
> >>>>>>>>
> >>>>>>>> Good luck!
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Sorry, but I consider the use of fakeroot a good thing, it
> >>>>>>> helps to reveal errors while packaging/creating the PKGBUILD
> >>>>>>> at least. Don't know why it should be avoided.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> fakeroot make a table of function pointers for many file
> >>>>>> manipulation calls, like open(), close(), chmod() and etc ->
> >>>>>> overhead, slowdowns (small of course)
> >>>>>> During the build process file perms are not necessary to be
> >>>>>> "tracked", or at least in 99% of packages. Only during the
> >>>>>> install process is only needed.
> >>>>>>
> >>>>>> If you have an example that breaks this, please let me know ;)
> >>>>>>
> >>>>>> --
> >>>>>> Gerardo Exequiel Pozzi ( djgera )
> >>>>>> http://www.djgera.com.ar
> >>>>>> KeyID: 0x1B8C330D
> >>>>>> Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C
> >>>>>> 330D
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Nice feature! I didn't know that using package() avoids using of
> >>>> fakeroot.
> >>>>> Back to my point. There used to be a problem with compilation of
> >>>>> amarok1 package from AUR only because of fakeroot and I guess
> >>>>> that it would also help with building of mplayer (configure
> >>>>> crashes under fakeroot environment and needs to be patched but
> >>>>> maybe it was fixed meanwile alongside with amarok1 problem). So
> >>>>> in some specific cases I can see the point of using separate
> >>>>> package() even when the PKGBUILD builds only one package.
> >>>>>
> >>>>> best,
> >>>>> Lukas
> >>>>>
> >>>>>
> >>>> ;)
> >>>>
> >>>> Most reported crashes on bugtracker are because nvidia libgl,
> >>>> that conflics with libfakeroot, both uses dlsym() (nvidia i
> >>>> don't know why does this, fakeroot do this to fill a table of
> >>>> pointer to functions), the result is a jump to NULL :P
> >>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024#75
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Gerardo Exequiel Pozzi ( djgera )
> >>>> http://www.djgera.com.ar
> >>>> KeyID: 0x1B8C330D
> >>>> Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C
> >>>> 330D
> >>>>
> >>>>
> >>>>
> >>> Hi Gerardo can you confirm that there are no (owner) permission
> >>> issues when building without fakeroot (i.e all owned by user)? I
> >>> don't see chown anywhere other than extract_sources().
> >>>  
> >> If your packaging is done properly, then there is no issues.
> >> Always use "install" and not "cp".
> >>
> >> Allan
> >>
> > 
> > I've often seen cp used in makefiles, would this cause problems?
> > Would you need to patch those makefiles?
> 
> If it breaks stuff, then you should tell upstream that they makefile
> is crap.

So I guess this means it breaks?
I usually do. You'd be surprised how many don't know about DESTDIR and
use cp.


More information about the aur-general mailing list