Re: Retreive installed gnustep version

[Riccardo Mottola]

Hi,

Ivan Vučica wrote:
> On Fri, Nov 8, 2013 at 10:23 AM, Riccardo Mottola <
> riccardo.mottola@libero.it> 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.
It is just different. We are speaking here of resources, which may be in 
a framework or an Application. Debian totally confuses this.
It makes sense for general installation where it doesn't really matter, 
that is, a usual program is not self-contained, a GNUstep Bundle is.
> > 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).
It has to do with that! Why should the user look for that resource? It 
is a program thing.
> > 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.
It is not. It is not consistent, it is just a hypocritical facade.
> > 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...
No, one shouldn't but it was the example of how this system doesn't 
makes sense. Of course you want to trust your package manager.
> 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?
No clue....
> 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.
I strongly disagree. It breaks the GNUstep experience.

Also, a user may have the right to install an app from source, along 
side debian packages. His installed app will be a bundle, making a 
pretty big mess.

It would be more consistent if ll Debian managed packages would end up 
as *Bundles* in /System and all user-installed stuff in /Local. System 
being, of course, not user-wide writable.

That is how I would expect it.
> 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.
For a time I was in contact with Yavor, he also wrote here. I imported 
several of his debian-local packages!

Riccardo