Re: Considering /opt and MyDocs in your packages
On Friday 11 September 2009 09:56:14 Marius Vollmer wrote: > Hmm, I am really in a detail-oriented "let's get this done" mode. As I > said, the question of whether or not and if so how to use /opt for > distribution packages is bigger than this, and I don't think we should > try to answer it here. So, given all the controversy and discussion, why don't we start with the simple hack. Let's decide that for the short term, any package (or group of packages forming an application) which is over (say) 500K SHOULD (not MUST) use the maemo-optify hack or some other mechanism to put most of its data somewhere in /opt. Yes, I hate all the symlinks but it will do the job for now. But don't try to force it on all applications, or do it automatically. Just get the maintainers of the big, commonly installed apps to agree to use the hack for now. I am assuming that there is no way that, at this late stage, Nokia would even consider any serious changes to filesystems (such as union filesystems, etc.). So, much of this discussion is about how it can get fixed in the medium term. The **really** interesting question is going to be whether someone can come up with a solution which Nokia can (and will agree to) apply in a Fremantle update! Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Fri, Sep 11, 2009 at 10:32, Marius Vollmer wrote: > > Yes, but is not in the same namespace as the distribution > packages. As you point out, one should register the names > with Lanana. (I didn't know about this, thanks for the information.) No, according to the FHS needs to be registered with LANANA, not individual packages (and so only if you use /opt//). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Martin Grimme writes: > I don't think /opt/ is a bad idea, and I wouldn't call it a > hack. On other Unices, like Solaris, 3rd party software usually goes > to /opt. In fact, by default, /usr is write-protected in virtual > containers (mounted read-only from the host system). I like to see Maemo as a traditional, all-inclusive distribution. As such, the stuff in Maemo Extras is as 1st party as any other package. (True, some package are more equal than others, such as the OS meta-packages, and some repositories are also more equal than others, such as the System Software Updates repo, but these things are not really "Us vs You".) > The good thing IMHO about /opt is that all stuff resides in one place, > not being scattered all across the filesystem. That's just on the surface. If you have a reasonable package management system, it doesn't make any difference either way. I do agree that the traditional Unix filesystem layout is not very clean, but it is also not broken and I don't want to try to fix anything about it within this excersize of finding more space for applications. > When looking at Solaris, you can find directories like "lib" and "bin" > inside /opt//. This way it's also possible for programs to > bring in libraries that would otherwise break or mess up the root > system. They can do this without /opt as well, of course. > LD_LIBRARY_PATH, etc. can be setup by the start scripts of the > programs accordingly. I'm all for keeping the root system clean of 3rd > party stuff. Knock yourself out, I am not stopping you. :-) But I also don't want to make this optification any more complex than it needs to be, for the sake of something non-trivial and fuzzy as cleaning up the Unix filesystem layout. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Hi, I don't think /opt/ is a bad idea, and I wouldn't call it a hack. On other Unices, like Solaris, 3rd party software usually goes to /opt. In fact, by default, /usr is write-protected in virtual containers (mounted read-only from the host system). The good thing IMHO about /opt is that all stuff resides in one place, not being scattered all across the filesystem. When looking at Solaris, you can find directories like "lib" and "bin" inside /opt//. This way it's also possible for programs to bring in libraries that would otherwise break or mess up the root system. LD_LIBRARY_PATH, etc. can be setup by the start scripts of the programs accordingly. I'm all for keeping the root system clean of 3rd party stuff. Regards, Martin 2009/9/11, Kees Jongenburger : > On Fri, Sep 11, 2009 at 11:11 AM, Marius Vollmer > wrote: >> ext Graham Cobb writes: >> >>> On Thursday 10 September 2009 12:16:59 Marius Vollmer wrote: >>> Also, you can make it so that maemo-optify only runs in debian/rules when it is present: which maemo-optify && maemo-optify >>> >>> Small correction: that doesn't work (because it returns an error status >>> when >>> maemo-optify is not present). > About the maemo-optify usage. > > The opkg package manager support a offline root mode that allows you > to install packages using a different base. The idea > is that one might want to install some content on a removable media. > it doesn't require you to change the > packages. perhaps this is a less intrusive option? > > > Greetings > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Kees Jongenburger writes: > The opkg package manager support a offline root mode that allows you > to install packages using a different base. Like dpkg's --root option? > The idea is that one might want to install some content on a removable > media. it doesn't require you to change the packages. perhaps this is > a less intrusive option? Nah, come on now. None of the packages will work if you install them somewhere else than in /. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Fri, Sep 11, 2009 at 11:11 AM, Marius Vollmer wrote: > ext Graham Cobb writes: > >> On Thursday 10 September 2009 12:16:59 Marius Vollmer wrote: >> >>> Also, you can make it so that maemo-optify only runs in debian/rules >>> when it is present: >>> >>> which maemo-optify && maemo-optify >> >> Small correction: that doesn't work (because it returns an error status when >> maemo-optify is not present). About the maemo-optify usage. The opkg package manager support a offline root mode that allows you to install packages using a different base. The idea is that one might want to install some content on a removable media. it doesn't require you to change the packages. perhaps this is a less intrusive option? Greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Fri, Sep 11, 2009 at 08:15, Henrik Hedberg wrote: > > It seems that the overhead of using UnionFS is about 10% [1], which > should be noted when making decisions. This performance lost will affect > all files, not should "optified files" as in the original plan. The article in question *is* five years old, and I believe the preferred union FS solution wouldn't be UnionFS, it'd possibly be aufs or one of the others explored by Valerie. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Simon Budig writes: > Marius Vollmer (marius.voll...@nokia.com) wrote: >> The "/opt is hack" statement needs to be qualified, of course. "Moving >> stuff into /opt/maemo" is a hack, of course. But at least in my >> opinion, "Moving stuff into /opt//" is a bigger hack, and a >> bigger violation of the letter and spirit of /opt. *shrug* > > Uh, I am not sure about this. > > Reading the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/) > it seems that both uses (/opt/maemo/* and /opt/) are covered > by it. Yes, but is not in the same namespace as the distribution packages. As you point out, one should register the names with Lanana. (I didn't know about this, thanks for the information.) I feel confident that we can get away with "maemo" without registering it. Using /opt/nokia feels wrong, since it gives the impressions that everything under /opt/nokia is actually provided by Nokia, which isn't true, and strictly speaking we would have to use /opt/nokia/maemo anyway since /opt/nokia is for all of Nokia, not just for our little hack here. Anyway, let's not discuss this to death. Patches to maemo-optify are welcome as long as they don't change the current default behavior of putting things in /opt/maemo. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Marius Vollmer (marius.voll...@nokia.com) wrote: > The "/opt is hack" statement needs to be qualified, of course. "Moving > stuff into /opt/maemo" is a hack, of course. But at least in my > opinion, "Moving stuff into /opt//" is a bigger hack, and a > bigger violation of the letter and spirit of /opt. *shrug* Uh, I am not sure about this. Reading the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/) it seems that both uses (/opt/maemo/* and /opt/) are covered by it. In fact configuring applications with --prefix=/opt and installing to /opt is not. (for /opt/maemo one apparently should register "maemo" with http://www.lanana.org/ which is apparently not really a problem: "nokia" and "nokiasiemensnetworks" are already registered) > I don't think using /opt/ in distribution packages is good > design. True. Bye, Simon -- si...@budig.de http://simon.budig.de/ simon.bu...@kernelconcepts.de http://www.kernelconcepts.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Graham Cobb writes: > On Thursday 10 September 2009 12:16:59 Marius Vollmer wrote: > >> Also, you can make it so that maemo-optify only runs in debian/rules >> when it is present: >> >> which maemo-optify && maemo-optify > > Small correction: that doesn't work (because it returns an error status when > maemo-optify is not present). Right, sorry for hastily posting untested code. (I should know better not to do that.) > Is the idea that the autobuilder will automatically install maemo-optify if > it > exists for that version or do we have to add it to our Build-Depends? Good question. I haven't really thought this through, obviously... :-/ Right now I would say that the buildbot should automatically install it, but maybe that is a bit brittle. What about uploading a version of maemo-optify to all buildbots, and only the one in Fremantle does any actual optification? Or we could do something more general ala the type-handling package in Debian. We could have a package that Provides virtual packages like "fremantle", "not+fremantle", "diablo", "not+diablo" as appropriate for the distribution it is in, and then packages can have Build-Depends like Build-Depends: maemo-optify | not+fremantle Might be overkill, dunno. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Andrew Flegg writes: > On Thu, Sep 10, 2009 at 16:20, Marius Vollmer > wrote: >> ext Andrew Flegg writes: >> >>> Although a unionfs solution would be a bit more further dev on Nokia's >>> part, it will reduce the developer complexity and gives us a real >>> world solution now. [...] >> >> Yes, agreed. Let's give this unionfs thing a shot. I was previously >> arguing against it, but only as a long-term solution. As a >> Fremantle-only hack, it might be better than the /opt hack. > > Cool. I should also point out that when I say "a unionfs" solution, I > mean "a union FS" solution; rather than advocating unionfs over aufs > (for example). Thanks to Stskeeps/Carsten for picking me up on that. Noted, thanks! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Andrew Flegg writes: > On Thu, Sep 10, 2009 at 16:12, Marius Vollmer > wrote: >> ext Andrew Flegg writes: >>> >>> Instead of using a fixed prefix of /opt/maemo/, use >>> /opt//. >> > [big snip] > > I'm not going to get into a point-by-point rebuttal of these. Hmm, I am really in a detail-oriented "let's get this done" mode. As I said, the question of whether or not and if so how to use /opt for distribution packages is bigger than this, and I don't think we should try to answer it here. People haven't really used /opt in their packages until now, and nothing really has changed to reconsider this on a massive scale. The name "/opt" that appears in this discussions is a big giant red herring. Just pretent it really was "/space" all the time, and I hope you can see how different the discussion would have been. > But installing stuff in /opt on Maemo by third-parties isn't really > going to happen. Maybe not, but that's no reason to repurpose the whole of /opt. You could also say that Maemo will never really be multi-user, but that's no reason to get rid of /home/user. > We own the space, pretty much everything is going to be installed from > packages, and we already make all manner of assumptions in a Linux > system that there's some unique "UNIX name" for a package. Why *not* > make the one-line change to maemo-optify to make its results slightly > cleaner? Because it's not cleaner in my view, it would be an even bigger abuse of /opt than hiding things in /opt/maemo. If you really care, we can make this an option to maemo-optify, and you can use it in your packages. I will still recommend the default of just moving everything to /opt/maemo without any further distortion. >> - Computing the from is an extra complication, >> and we must make sure that no collisions happen. It's doable of >> course, but in the light of the arguments above, why bother? > > ...because /opt is a hack because no-one at Nokia had the foresight to > imagine that users might want to install multiple applications, and > large new frameworks like Qt. The "/opt is hack" statement needs to be qualified, of course. "Moving stuff into /opt/maemo" is a hack, of course. But at least in my opinion, "Moving stuff into /opt//" is a bigger hack, and a bigger violation of the letter and spirit of /opt. *shrug* > ...because /opt is a hack which should be *embarassing*. It is! > ...because maemo-optify creating a forest of symlinks is messy, > unelegant and possibly prone to failure (see my earlier question about > Python modules and sub-directories of optified packages). If I understand your proposal here right, we would still have the same forest of symlinks, just more messy since they have a more complicated pattern. > Mainly, though, because last minute fixes shouldn't throw good design > out of the window. I don't think using /opt/ in distribution packages is good design. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Andrew Flegg wrote: > > ...because /opt is a hack because no-one at Nokia had the foresight to > imagine that users might want to install multiple applications, and > large new frameworks like Qt. It wasn't really hard to see this coming. We are booting from MMC since the OS2006 days and one of reasons users do it is that the space in internal NAND is too small. 3 years later someone noticed this problem and we have this ugly /opt hack done in last minutes. Oh well ;-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
David Weinehall wrote: > IMHO we have three options: > > - Real VFAT (with all the drawbacks it brings) > - VVFAT > - A separate program (PC Suite, most likely) to do the transfers > (probably leaving Linux and MacOS users out in the cold) There is also MTP [1]. It is less generic than one would want but still it tries to solve this problem. Too bad there is no generic USB standardized filesystem gadget. 1. http://en.wikipedia.org/wiki/Media_Transfer_Protocol ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Fri, 2009-09-11 at 09:15 +0200, ext Henrik Hedberg wrote: > Kimmo Hämäläinen wrote: > > > Does UnionFS support block rotation (like ubifs) for the internal flash? > > UnionFS works on top of other file system(s) in directory level. In > this case, UBIFS would be still there for the underlying root filesystem. > > It seems that the overhead of using UnionFS is about 10% [1], which > should be noted when making decisions. This performance lost will affect > all files, not should "optified files" as in the original plan. Maybe it could be used selectively for installed applications only. I think the 10-12% speed loss is not going to be accepted for all file system access (doesn't make sense either if it can be avoided). -Kimmo > > BR, > > Henrik > > [1] http://www.linuxjournal.com/article/7714 > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Kimmo Hämäläinen wrote: > Does UnionFS support block rotation (like ubifs) for the internal flash? UnionFS works on top of other file system(s) in directory level. In this case, UBIFS would be still there for the underlying root filesystem. It seems that the overhead of using UnionFS is about 10% [1], which should be noted when making decisions. This performance lost will affect all files, not should "optified files" as in the original plan. BR, Henrik [1] http://www.linuxjournal.com/article/7714 -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problem in Building Application
On Fri, 2009-09-11 at 07:43 +0200, ext Venugopal Rao Gubbala wrote: > Hi, > > I am new to maemo Platform. I have downloaded mweather application from > garage and while trying to build it I am getting > Following error. > > I am getting error while running ./configure. " > > It says No package 'hildon-lgpl' found" Can any one tell me how to fix > this issue or how to install "hildon-lgpl". I tried googling but was > not successfull. hildon-lgpl has been removed 2.5 years ago, please use libhildon1 instead. -Kimmo > > Maemo 5 installed on my system and Operating System is Ubuntu Jaunty. > > Command prompt out put is :: > > [sbox-FREMANTLE_X86: ~/App/mweather] > ./autogen.sh > + libtoolize --automake > + aclocal-1.7 -I m4 > + intltoolize --automake > + autoconf > + autoheader > + automake-1.7 --add-missing --foreign > > > [sbox-FREMANTLE_X86: ~/App/mweather] > ./configure > checking for a BSD-compatible install... /scratchbox/tools/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking for style of include used by make... GNU > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking dependency style of gcc... gcc3 > checking for gcc option to accept ANSI C... none needed > checking for gcc... (cached) gcc > checking whether we are using the GNU C compiler... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to accept ISO C89... (cached) none needed > checking dependency style of gcc... (cached) gcc3 > checking how to run the C preprocessor... gcc -E > checking whether make sets $(MAKE)... (cached) yes > checking whether ln -s works... yes > checking for a BSD-compatible install... /scratchbox/tools/bin/install -c > checking whether NLS is requested... yes > checking for intltool >= 0.21... 0.40.5 found > checking for intltool-update... > /scratchbox/devkits/doctools/bin/intltool-update > checking for intltool-merge... /scratchbox/devkits/doctools/bin/intltool-merge > checking for intltool-extract... > /scratchbox/devkits/doctools/bin/intltool-extract > checking for xgettext... /scratchbox/tools/bin/xgettext > checking for msgmerge... /scratchbox/tools/bin/msgmerge > checking for msgfmt... /scratchbox/tools/bin/msgfmt > checking for gmsgfmt... /scratchbox/tools/bin/msgfmt > checking for perl... /scratchbox/tools/bin/perl > checking for XML::Parser... ok > checking build system type... i486-pc-linux-gnu > checking host system type... i486-pc-linux-gnu > checking for a sed that does not truncate output... /scratchbox/tools/bin/sed > checking for grep that handles long lines and -e... /scratchbox/tools/bin/grep > checking for egrep... /scratchbox/tools/bin/grep -E > checking for ld used by gcc... > /scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu/bin/ld > checking if the linker > (/scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu/bin/ld) is > GNU ld... yes > checking for > /scratchbox/compilers/cs2007q3-glibc2.5-i486/i486-pc-linux-gnu/bin/ld option > to reload object files... -r > checking for BSD-compatible nm... /scratchbox/compilers/bin/nm -B > checking how to recognize dependent libraries... pass_all > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking dependency style of g++... gcc3 > checking how to run the C++ preprocessor... g++ -E > checking for g77... no > checking for xlf... no > checking for f77... no > checking for frt... no > checking for pgf77... no > checking for cf77... no > checking for fort77... no > checking for fl32... no > checking for af77... no > checking for xlf90... no > checking for f90... no > checking for pgf90... no > checking for pghpf... no > checking for epcf90... no > checking for gfortran... no > checking for g95... no > checking for xlf95... no > checking for f95... no > checking for fort... no > checking for ifort... no > checking for ifc... no > checking for efc... no > checking for pgf95... no > checking for lf95... no > checking for ftn... no > c
