"Giorgio Lando" <patroclo7@gmail.com> wrote:
Hi, I am a relatively new CRUX user (I come from Gentoo and Archlinux)
I was an Arch Linux developer and user and partially used Gentoo before I switched to CRUX.
and I really appreciated CRUX typically slow and unobstrusive development, without overburocratized patch management system and without the need to change just to change. CRUX sometimes seems dead, just because it is following linux development without adding any complexity and obstrusity. This is why footprint mismatches should be analyzed directly by the users (something new is entering their system, they have to decide what to do) and why use flags are a way to obfuscate the way a package is built (a user should directly verify how a specific package is compiled editing the Pkgfile).
Footprint mismatches occur, because the user has other software installed than the developer who generated the footprint. Configure (autotools) enables additionally features and additionally files are installed. Thus the footprint mismatches. Isolated builds and feature flags (~ USE flags) prevent this situation. Additionally feature flags use configure correctly (in the way it was intended to be used).
Moreover, in the past six months, I have sent several observations about the way some packages are built and each one has received an answer: the aim of my remarks was never to introduce something peculiar or deviant in the way to build packages, but merely to fix mistakes.
But sometimes it is impossible to do so, because of configure.
I do not see why C++ would have been so essential to the spirit of CRUX: there is no precise design or aim behind that choice, and the advantages of C over C++ are, I would say, well known.
Yes, but including standard algorithm source code (lists, binary search trees) conflicts (in my opinion) with the design philosophy of CRUX. Additionally I think the pkgutils C++ source code is much more aesthetic and clean.
Moreover:
* (perhaps) merge with CRUX-PPC
A little distribution should not try to work on multiple architectures, because this implies a massive dissipation of efforts: CRUX is designed to work on i686 machine and should not try to be something else
In the 1970s UNIX and C were designed to make the operating system portable. The success of UNIX is based on this. GNU would not exist if UNIX had not been portable. According to your argumentation operating systems would be written in Assembler. This is really stupid if you have the chance write a portable version of it. Nearly all ports are written in portable languages and work on every architecture. Why should CRUX restrict their usage to i686?
* more precise and stricter packaging standards
I see no point in this, and many disadvantages affecting distros like debian, gentoo and archlinux: a huge burocracy checking unuseful stuff like the order of fields or the kind of quotation marks deployed.
These standards ensure the quality of the software. The examples you mentioned do not reflect the real intention or usage of this standards.
* complete localisation (no --disable-nls, ...)
I do not need localizations, because their only point, besides wasting disk space, is to obfuscate the original language in which a software is thought and written. They are useful in distros aimed to newbies and casual users who are allowed to ignore english, but the experienced users of CRUX will surely know English well enough (otherwise they could not be really involved in the development of linux) and do not need to be mislead by potentially wrong translations.
I have been working on a big translation project and I know that even experienced users liked and wanted it. I do not need translations, but they are included in the packages, so why should we reject them? Maybe other user on your system want them. You can disable them via events/hooks in pkgutils if you do not want them.
Other wishes are more vague and could be partially shared. But they do not require any change of mind towards an heavily organized, obstrusive way of development.
You need some kind of organisation for every non-trivial project. It may not be hierarchical, but there needs to be some standards in order to collaborate effectively. -- Matthias-Christian Ott