discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FHS filesystem layout issues [was: Re: Request for update and/or rel


From: Markus Hitter
Subject: Re: FHS filesystem layout issues [was: Re: Request for update and/or release of GDL2 and Renaissance]
Date: Thu, 30 Jan 2014 18:25:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Am 30.01.2014 15:42, schrieb Niels Grewe:

> 1. I don’t understand why you are not reporting these problems to the
> list or the bug tracker.

A couple of reasons:

- Looking at this -make documentation failure bug report, the very first
answer from a developer was to close the bug. Later it was refused to
reopen it. Intially the defending statement was "read the
documentation", later it was exactly the opposite, "things should just
work". All done with a refusal to execute the provided commands and
extreme amounts of argumentation for such a simple issue. The patch
eventually applied had only fragments of the provided patch, notably, it
kept dead code and added useless ("nice to have") stuff. Together, one
could describe this as "fight the bug reporter at all costs". The time
spent into such an adventure is undoubtly invested much better in
writing code.

- I've talked to many people by email, IRC, here, watched other
conversations. There's barely an acceptance problems actually exist.
Instead people try very very hard to find reasons for avoiding changes.
How can a piece of software evolve if the very first goal is to not
change it?


> So I can only hope that these are the right
> ones:
> 
> http://bazaar.launchpad.net/~thopiekar/gnustep/gnustep-make-packaging/files

This is the work of Thomas. He went the trivial way and installs with
the bundle layout, ignoring documentation, lintian issues and Debian
packaging guidelines. The advantage of this approach: no build issues
and likely working GNUstep applications. Disadvantage: not acceptable
for debian packagers, so no appearance in official package sources.

You had the links to an debian guidelines compliant approach already,
even quoted them. Let me quote the quote:

>> The result is here:
>> 
>> (first attempt)
>> https://launchpad.net/~mah-jump-ing/+archive/ppa/+packages
>> 
>> (second try)
>> https://launchpad.net/~gnustep-dev/+archive/weekly/+packages
>> 
>> First try results in something not working not well enough to build an
>> application. Second try with very vague results. More than a dozen
>> patches required, bundle-style stuff ripped apart to align with FHS
>> demands. Still pictures in /usr/lib, where they don't belong by FHS
>> standards. This isn't packaging, but porting.

If you want to see the code used for packaging, click on "View package
details, open the package you're interested in, then download the
...debian.tar.gz file. Sources are there, too, in the ...orig.tar.gz
file. They should match SVN sources of the same day, plusminus a few
commits.

The BIG question with all this is: can you actually build and run an
application on top of this?


> I think we can sort this out if you
> can provide us with a list of things where we deviate from the FHS
> standard.

A _first_ thing would be: GNUSTEP_INSTALLATION_DOMAINS represent a
concept which doesn't exist on FHS systems. There's a concept targetting
a similar goal, it's using --prefix at configuration time. For FHS
systems, this installation domain thing should go away. For bundle
systems, --prefix should go away. For both, domains and prefix shouldn't
be mixed.

Essentially this means:

- There are only two kinds of (supported) filesystem layouts, FHS and
bundle-type. The other ones are obfuscating clutter.

- One way to join bundle-type with configure could be to set --prefix
according to the choosen domain on bundle-type layouts, ignoring the
--prefix given at the command line.

- If you really want to install into unusual places, like packaging,
there's always DESTDIR.

- There's a good chance this requires ObjC code changes to deal with the
non-existence of domains on FHS systems.

- Lots of code changes in the build scripts/makefiles, of course.

- All this has to be persistent. Once a user installs -make, every
GNUstep thing built with it has to use the same choice of FHS vs. bundle
without requiring developer attention.


Good luck with explaining such changes to people who still search for
gcc 2.95 support.


Markus


P.S.: when starting last December, I didn't want to become a GNUstep
developer. I just wanted to run GNUmail or Apple Mail on Ubuntu. That's
still my goal.

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.reprap-diy.com/
http://www.jump-ing.de/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]