On 11/04/2009, at 6:09 PM, Quentin Mathé wrote: > However setup.sh needs also to be reworked to better integrate with > packager needs. I have no experience with packaging at all, so I more > or less wrote setup.sh as a quick solution when you compile and > install everything manually.
Yes, it does seem like a convenience script for people compiling manually. I suppose for that purpose it is good. However, it would be nice for a more standard solution to be provided for packaging purposes. Personally I would move toward having everything in the Makefiles (if possible), and instructions for everything else (like setting up the PostgreSQL database for CoreObject). > It could be better to move some parts of the script back into in the > modules they are related to. For example, SystemTaskList.plist could > be installed by System GNUmakefile, or perhaps even installed lazily > when etoile_system is launched and cannot found this plist file. I think installing it through the relevant module's Makefile would make the most sense. >> At this point it seems I would have to replicate some of the ./ >> setup.sh script (copying files) in the PKGBUILD. Writing the defaults >> is per-user, so it can't actually be done during the packaging >> process. I could put it in the install scriptlet, but this would only >> set the environment for the user installing it (probably root). > > For this point, would it be better to have a script that is run the > first time the environment is started? We could do that… I think so. This is probably a problem with the GNUstep common Makefiles rather than Étoilé, but it seems some things (mostly frameworks) are linked, rather than copied into the installation directory. This results in broken symbolic links on the user's system. I can fix it up in the package, but this seems like a bug to me. Actually, I don't think those links should even exist. System/Library/Frameworks/PopplerKit.framework/PopplerKit.framework System/Library/Frameworks/EtoileUI.framework/EtoileUI.framework etc... Is this normal? Is Etoile/Themes supposed to be empty? On 11/04/2009, at 10:40 PM, Sourav K. Mandal wrote: > On Sat, 2009-04-11 at 15:07 +0800, Sebastian Nowicki wrote: > >> At this point it seems I would have to replicate some of the ./ >> setup.sh script (copying files) in the PKGBUILD. > > The Gentoo ebuilds don't use the script at all, and just use > gnustep-make's facilities for building and installing. The major step > is to set the environment such that files are installed into the > temporary target directory; then, the package manager merges them into > the filesystem and records their paths for query or uninstall at a > later > date. Archlinux's packaging system is basically the same. There are problems with this even in the Makefiles, especially with symbolic links, as mentioned above. I don't see any hacks in the ebuild around that, so I'm assuming it's not a problem? Maybe it gets "magically" fixed. > Here is a link to the eclass that implements this: > > http://mirrors.usc.edu/pub/linux/distributions/gentoo/eclass/gnustep-base.eclass > > Look especially at 'egnustep_env'. Here is a link to the daughter > eclass: > > http://mirrors.usc.edu/pub/linux/distributions/gentoo/eclass/gnustep-2.eclass > > The Etoile ebuilds using this daughter eclass (and thereby the base > eclass) are here: > > http://overlays.gentoo.org/proj/gnustep/browser/overlay > > Note how these builds basically do nothing. Thanks, I was looking at the ebuild, but I gave up at looking into it deeper. I hate it when stuff is that implicit/magic. It doesn't seem to do much beyond sourcing the GNUstep.sh, which I am already doing. the package, as it is now, works fine for me, but I don't use etoile_system. The Makefiles don't install SystemTaskList.plist and other files, yet I don't see the ebuild installing those either. It seems the PKGBUILD and ebuild do pretty much the same thing at the moment. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
