On Fri, Nov 8, 2013 at 10:23 AM, Riccardo Mottola < [email protected]> wrote:
> > this is against the GNUstep Bundle concept. > > If you have instead a real gnustep bundle, it is self-contained. > Trouble is, both GNUstep and Debian are correct here. Debian people are completely right to break up the package, or else every software developer would package things to their preference and Debian would be a mess. It's not that GNUstep approach is wrong, it's that Debian people try to make every package conform. Game developers like to throw an executable next to .dlls next to data files. But, on Debian, all user-accessible executables should be in /usr/bin. Any internal additional executables (and possibly .so's)? /usr/libexec/packagename. Any log dumps? /var/log. Any documentation? /usr/share/doc/packagename. As a user, I know where to find files on Debian at all times. GNUstep approach ends up as a casualty. > > Do you know how easy it is in theory to install an application? copy it > into /Local/Applications or if you prever it system-wide, then move it into > /System/Applications or /Network/Applications > > That's it. Why break it up? the purpose of "share" would be to share a > resource but > 1) gnustep "shares" the usage with frameworks, bundles, etc > 2) if you put it in /usr/share/GNUstep/ViewPDF.app/Previous.png, it is a > "fake" sharing, it is private to ViewPDF anyway. So it is fake compliance > > So, at the end, I think you gain nothing, but break the toy. Except the user then knows where to find ALL resources. All resources are in /usr/share. It has little to do with sharing (the names of the folders have long ago lost most of the connection to the actual use). If everyone adopted bundles, sure, it would be preferable to have self-contained application bundles containing all resources. (Perhaps in the Resources/ subfolder, as on OS X.) I like the concept of installing an application by unpacking it and just running it from wherever I want (preferably something like /Applications or /System/Applications.) But you won't see the Evolution developers adopting the application bundle approach any time soon. Nor will you see any of the thousands of other FLOSS GUI application developers adopting the bundle approach any time soon. So the maintainers of all applications in Debian go through the process of breaking it up into pieces, patching the application along the way to work with new paths, just to get a (somewhat!) consistent directory layout for the users. Personally, I use Debian-based distributions precisely because if a package is in the distribution, I can know files will end up in places that are easy to find. Besides, if a package is installed through dpkg, then it's managed by dpkg -- installed, updated, uninstalled, even system-wide reconfigured. One would NOT move the application bundle around even if it were in one piece... I do want my packages maintained by dpkg. But I also want them to be up to date The actual issue with Debian packages is that they get rare updates. For example, I just checked out http://packages.debian.org/gnustep-gui - and the current release did not update since wheezy. Only in the "experimental" suite (that no end user in the right state of mind will have installed) do we see an update to 0.22.0... and there's already a 0.23.1 release. What is going on there? Applications in Debian packages do need to be broken up for consistency with the rest of the system. Even if looking at single package such as ViewPDF makes one wonder what sense it makes, in the big picture, it's better. But the slow updates are somewhat inexcusable. It would be fantastic if the Debian maintainers would chime in with information of how we could help with getting the packages up to date faster. I'll try to spend some time over the weekend making the Debian packages produced by "make deb" actually useful -- e.g. by adding support for specifying dependencies, package descriptions, etc into GNUmakefiles. I'll target (and have previously targeted) Ubuntu, but this should hopefully work with Debian. Perhaps it'll help Philippe when he's updating his set of packages, too. -- Ivan Vučica [email protected]
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
