Le 28.11.2012 20:32, Miles Fidelman a écrit :
"Morel Bérenger" wrote:
(Personally, I'm suspicious of software and changes that are
distribution-specific.)
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
checked.)
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...)
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8559646c0aeb1ec985cd053abf9ff...@neutralite.org
