Ivan Vučica wrote: > On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov <[email protected]> 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.
