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

Re: how many users is enough? (was Re: Debian Installer 7.0 Beta4 release)

Le 28.11.2012 20:32, Miles Fidelman a écrit :
"Morel Bérenger" wrote:
(Personally, I'm suspicious of software and changes that are
Are you suspicious about the Debian Linux kernel? It have distro specific patches. (But I think and hope that they are reported upstream. Did not

Well, that's why I included this:
| Now where the number of users/contributors might really come into play is when it comes to maintaining/developing those aspects of | Debian and Ubuntu that are unique to the respective distros (e.g., their installers and package repositories).

I really think that the packaging is not so easy as it sounds. If it was, all developers would provide packages automagically generated for all distros, and this >> would not require maintainers. But strangely, that's not so common. Maybe because it's not that simple...
Well... I usually find that ./configure; make; make install works automagically on most distributions - usually more reliably than packaged versions of more obscure code.

I will only speak about things I have seen, as a developer which only contributes to (some very rare) free softwares in his spare time (I would be happy to do so in professional time, trust me :) ). I did only tried Debian (and 10s of Ubuntu, ages ago, plus a try to install fedora recently, stopped at the first question I was not able to translate in terms I know. And windows, of course, for my job.) and did not tried many build systems: Visual Studio, Code::Blocks, qtcreator, eclipse and CMake. (yes, IDEs are included, because they integrate build systems) I can also only speak about C and C++ build systems, because when something works for C, it _often_ works for C++, which is currently the language I am using in my spare time. (just love it) I am not a script writer, too. They use different ways to think as my favorite language (type safety is just one example). And finally, I have uses vim (for small projects of 2-3 implementation files), but I never tried emacs. And I do not intend to, for some reasons (I use vim because it is a convenient tool, but not perfect, because hard to configure. emacs with a programming language that I do not master can only be worse, and I do not want to copy/paste. Those are some reasons. Not all.).

You said that "$./configure; make; sudo make install" works easily.
You are right, every time I wanted to run them, things worked not so bad.

But... are they built automagically by a *SIMPLE* tool?
If yes, I did not found it.
Oh, and, by simple, I mean an easy to use and configure tool, of course. Not simple in the "do only one thing" way (yes, sysvinit -this is an example, please do not troll- is simpler that other main processes, but what about the easiness of configuration for someone who discover the system? Personally, I am unable to understand the boot procedure on my linux OS, and am not ashamed by that... Thousands of lines to read in hundreds script cryptic files... no reason to be ashamed of being unable to understand them...) One which does not require the user to learn yet another black magic programming language... Haskel, lisp, make, shell, powershell, perl, C#, python, sql, brainfuck, prolog, asm, C, C++, B, D, JAVA, objC, vb, pascal.... I do not care which one, if I have to learn a language, then it is not simple. Do not troll about the better languages here, I do not mind that someone think one is better than others. (the next on my list of 'to-learn&use' is already in the list and I think no one will guess which one it is :P)

When I tried to look inside those scripts (configure and makefiles), I discovered... obscure text. Very obscure text. Insanely obscure text! Honestly, it is far easier to build your binary with your IDE or a shell script with hard-coded distro-dependent commands, create a "folder tree" representing the system, move (with a script) the files you have generated in the right destination, and write the small description file needed by dpkg to generate a .deb than creating a tool to allow people to dynamically build your software from a random environment, which have to be able to say they which dependencies are not right (it have because else, people will not even try to compile, even if you provide and IDE project file which can do the job. Linux users are so dogmatic... did someone noticed that often, there are a configure AND a visual studio project supported?) All of that can be made by a simple script written once and put in the "after-build" steps of your favorite IDE.

Problems in this simple procedure are things are machine and/or distro dependent: _ the "folder tree" will change depending the POSIX OS you will use. Not to speak about non-POSIX OS, which are the most commonly installed nowadays.
_ description file will change depending on the distro you are using
_ of course, ABI will break very often
_ there is also the hash (md5 of sha***, nevermind) which will change depending on libraries (this is related to broken ABI) _ There are also naming problems of libraries (a debian example: take "libboost.-dev* and it's "libboost.*" counterparts, and note that binaries have everytime the number version in the name... This have probably a good reason.)

As you can see, those differences are not trivials to manage. And only ABI issues can really be handled by the build system, but this one, excepted in source distros (gentoo, sourcemage...) , is not able to download and install dependencies. If a software had to use /srv/foobar in his "configure", how could you be sure that things are ok on RHEL? The distro constellation is a real problem, and I do not think all distros will finally decide to produce an installation standard with binary compatibility. And while such a standard does not exists, non closed operating systems will keep their "hard-to-install" reputation. Because for most users, an "#apt-get install mysoft" or "$wget www.fooware.org/mysoft;./configure;make;sudo make install" is hard to do. It can be true or not, they think, so it is. (and so it is hard to install malwares, too ;) )

Except if you know the panacea for all those problems, I do not think you should say such kinds of things are easy. And there are probably tons of problems I am not currently aware of, since I have not dived into binary distribution yet. And maybe I will never do, letting users taking care of contributing build and package systems. Ok, softwares will not be used by everyone... but is it always the goal of developers? (Yes, I know, I'm so selfish to share source code without generic way to compile/install...)

Reply to: