Ivan Vučica wrote:
On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov <yavor@gnu.org> wrote:
The answer is simple: because there's a lot to lose and nothing to
gain.
This is unfortunately wrong. There is a lot to gain.
Right or wrong depends on the point of view, which ultimtately boils
down to one's values and beliefs. What is gain for some may be loss
for others. It appears we have different values, hence the
discrepancy.
Developers who want to start using Debian-built GNUstep libraries
can start using tons and tons of features that GCC and GCC runtime
do not support.
Developers who want to start using these new (not so new -- 10 years
old!) features have the option to build the environment they need on
top of Debian (if that is their distro of choice) or switch to another
distro that provides prebuilt packages.
But that is the wrong answer.
You, developers, tend to forget that free software is for users.
Developers are users too in a broad sense but they are a very small
part of the whole mass of people using a particular piece of software.
If these fancy features existed for 10 years, why they have not
inclined developers to write more free software that is relying on
them? Surely that's not because Debian stopped them? Or because the
GNUstep project is stopping them?
My task as a free software contributor (with the extremely limited
skills I have) is to help achieve the goals of the Free Software
Movement. Providing "tons and tons of features" to developers who
don't care at all about free software (at least the majority of them)
and who won't write a single line of code for the cause I'm aligned to
doesn't strike me as the "right" thing to do.
I don't mind helping them as a side effect of helping free software.
In this case, however, it is all about them.
- ARC is one.
- Blocks is another.
- @123 syntax for NSNumber (and similar stuff for arrays and dicts and
more) is another.
- Improved @property support is yet another.
This is like offering rocket fuel to someone who has a car with a
diesel engine. None of the packages in Debian is using these
features, which is why I said there's nothing to win. There's a queue
of software packages we intend to package in Debian but neither of
them depends on these things -- except probably the Rik theme and
NEXTSPACE (which are not suitable for packaging for other reasons).
Right now I'm working on a new upstream release of a package which
uses NSNotificationCener-addObserverForName:object:queue:usingBlock:.
This is a method which is declared and supposed to be supported even
with GCC, I just don't know the (GCC) syntax I'm supposed to use so
I'm experimenting with GCC nested functions as replacement. If that
fails, I guess I'll solve it somehow, using a different approach.
That's the first case I face ever -- I've seen methods using blocks in
upstream code before but they were no-op anyway as there was no
GNUstep implementation. On the contrary, there are tons of
block-unrelated things which are not implemented, especially in GUI.
The biggest hurdle with porting apps IMVHO is missing functionality
and dependency on Core* stuff and other libraries with no free
implementation. The switch to Clang is not going to solve these
problems. The only thing it solves is making the life of developers
of properiatary software easy. That is not my goal.
But I'd say that Debian's packaging of GNUstep is very important and
even if the core doesn't start depending on these features, they
should be made available.
I don't know why Debian is important, but they cannot be made
available as an option. It would mean duplicate packages with
different names -- the release team will not allow it and the
ftpmasters will not allow it.
You probably weren't around when we (GNUstep people in Debian) had to
scrap and fight to prevent it from being removed. GNUstep in Debian
back then was undermaintained and violated the FHS, it was also full
of bugs (that is, obvious bugs such as frequent failures to build from
source) and blatant bugs solely due to packaging. Hubert wrote a tool
to FHS-ify most of the packages, we fixed most bugs and we had a
helping hand from the Debian GCC maintainers who said it would be very
worthwile to keep GNUstep in Debian, at least as a testing ground for
GCC.
And that's what it's been, more or less; GNUstep had a rapid decline
in the user base some years ago and it appears it is not going to
recover. All the Clangs in the world are not going to help you with
that. But in your quest for popularity you may lose some of the solid
foundations that are still keeping this project afloat.
What's lost is builds on some architectures. Can't those architectures
keep using GCC-targeting libraries or be actively disabled?
No. Packages which no longer build for a particular architecture must
be removed manually by the ftpmasters, after a request is filed. If
the architecture is official (meaning it is officially supported in
the stable version of the distro about to be released) it must be
decided by the release team.
In case it still isn't clear -- I repeat, there is no middle ground to
support both compilers/runtimes.