* Serge Jadot dnia [021223 03:09] napisales(-as):
> Ok, I thought that when you are saying "checkout entire arianne under=20
> linux" it was not only for EOL.
Ok.
> But my english is not very fluid, sorry.
My too, so don't bother :)
>=20
> >Arianne is still alpha,=20
> >and changing really fast now, so making any packages for now is useles=
s.
> What is changing? code or library. Code is a normal thing, but library=20
> is generally feld as a flight ahead.
True, code. Libraries are already released by they authors (we use
changed Kyra - so we supply with our cvs). If they are released, there
are packages with them for most distributions. I'm sure there are ones
for MDK - and they are specialy tweaked for it.
> I'm not agree with you. A *source* package may include all utilities to=
=20
> remake the code.
Oh, oh, autotools, all libraries, gcc??
> Mmmm, I dont <trol>... But in a *source* package we can hope to have al=
l=20
> necessaries and no more.
> Say me what you make when configuration, compilation or another step=20
> abort with an error?
You make what the error message said to do.
> Sometimes you try to upgrade a lib... but its not the good, aso... Time=
=20
> and disk space are lost :(
If there was an error you shouldn't blindly upgrade libraries, but see
what the error was, and if you don't understand it, or why is it there,
aske developers.
> Time is important for helpers because generally this time is after the=20
> job, the living comodities and familiar and social obligations.
Yeap, developers too.
> I suppose that a lot of beta-testers renounce when they tray, and=20
> retray, and retray,...without issues.
I will be harsh here - that's what beta-testers are for, not even saying
about alpha-testers.
Ok, ok, I really apreciate your work, we as developers too have limited
time, can't test everything, and yes we too try, retray and so on.
And we are trying to make the usage of software easy for testers, we are
really trying.
>=20
> Only that! You are exactly thinking as me, except I dont require for=20
> binary. Sorry i wasn't sufficently explicit. When I was spoking about a=
=20
Ok, I misunderstood you, sorry too.
> Ok, you dont know who am i and you will be pedagogic, but you say=20
> exactly the opposite idea before.
Not really.
> You are using made libs: of course! Question is: what version.
The proper one ;)
> A very great question! Some developpers are running always to the last=20
> library, the last tool,...
Heh, true. Have you ever considered why ?
Yes sometimes just because they are new, but more often because they give
sth that make work easier, and as you said our time is limited.
But most of the tools are not required on client side, look below.
>=20
> Ok, I'm an old and nasty tester: I play the idiot and (of cause after=20
> getting the last CVS) I write: autogen.sh as you say and without read=20
> any readme.txt
> ( we are near Xmas and I like to hope to santa Claus ;) )... and, oh=20
> surprise, I have this:
> "be sure you are using aclocal and automake > V1.6...
> continuing with a lot of errors..."
1. Harsh answer - if someone don't read readme he has what he wanted.
2. My answer - yes, when I was starting with OSS I haven't even notice
the readmes - I was coming from windows, and we all now how most of
readmes for win apps look like (License - do not touch this program,then
some mumbling about anything, and throubleshoting - i've never found
anything useful there). Then after some time I started to read them, and
guess what, they answered most of my questions, and helped me to not
have to rebuild the program few times before working (<- awful gramatic,
I hope you get it :/ ) In OSS developers don't like to waste they time,
so the don't write stupid readmes (ok, thay are some exceptions ;) ),
they put there answers to questions they got from users. So I too try to
write good, useful readmes - I have to learn it, though.
And that would be my answer. To the first tester, to the second... but
to the question from tenth tester, I would probably answer the harsh way.
> I check "aclocal --version" same for "automake" and I have version 1.4 =
!!!
> What a pity I'm testing the last version of MDK and I have in it an old=
=20
> version of aclocal!?
Could you try "aclocal-1.6 --version" or "aclocal-17 --version" ?
> Of course I know arianne is "alpha", but tomorrow it would be late to=20
> see if arianne works for everybody.
True.
> And this is what I will hope for arianne.
> Do you understand my idea?
Yes, I think so... but I do not agree... look below.
> You have only one solution to be effective: to have a freezed toolbox,=20
> and not to change with each releaze of the code.
First: having freezed toolbox is stupid - why to reinvent the wheel ?
If sth was added to some tool we should use it.
If I would stick to autotools 1.4 the build structure would be a real
pain in the ass. Especially later maintaing it...
About libraries - the ones we use aren't any bleeding edge, those are
normal, stable releases AFAIR (kyra is exception, but yes, it is shipped
from our cvs), and what's most important thay are binary compatible
between versions. So you can have newer or older, as long as it has the
features required.
And the authors of them, has put much effor to make it shipped as easy
as it can, then eople making distributions adapted it to the distrib.
Now, let's say we shipp the library with Arianne, it surly will not
compile on some system, who do you think will be asked why it is not
compiling? And I will have to explain, that's it is not part of arianne,
and so on. So it wouldn't really solve what you wanted it to solve,as I
can't quarantee that the library will compile - you must consider, to
compile them you will need some others, and to compile them... should we
ship alee of it in Arianne package? You were saying sth about hdd limit?
So maybe we should ship compiled libraries? But then, it too won't work
on half of boxes (especialy those with kernel other then linux I hope to
have arianne working on them sooner or later) because of some other
library incompatible. Second problem AFAIK default Linux instalations
do not search for dynamic linked libraries in current directory, so by
shipping libraries in apckage, I would have to install them in master
dir *overwriting* any present there. If now in arianne package will be
an older version, half of the system will be destroyed, not saying that
packaging system will lose control over this files (it will just
overwrite them sooner or later).
And yet another problem - it is agains standards in Linux. Let's assume
every software is shipped with full st of libraries:
a) every is putting them in some different directory - hdd limit again?
b) in one directory - oh oh, one is overwritting others, what if you
have installed arianne and then some other - newer soft but with older,
lets say sdl ? bum - arianne is not working
And at last - autotools - they are only needed when getting version from
CVS (for now the only way), when user will get a package he won't even
need to know what autotools are - configure and Makefiles.ins will be
already made.
Ufff, so it looks like that:
1) binary packages - built under some distrib (i will surely make some
for debian), with proper dependencies set - very easy to set up (net
yet available)
2) source package - no need for autotools, you have to care about
having proper libraries installed. I will try hard to catch all missing
things in configure, so you should never get a compile error. (not yet
available)
3) cvs update - mainly for developers, so proper autotools neede, and
probably some knowledge about it, or at least a little wish to try,
read, and think - I hope it will be sufficient :)
Yeap, and yes, the problem are testers ;) - as they are not yet a
developers, and not anymore ordinary users. I think some of them will
choose option 2) and I hope some option 3).
I will do what I can to make it as easy as possible. First I will modify
autogen.sh, as it is really stupid. And yes, saying that it will work
was, well, aliitle to ... optimistic ;)
Uff ;)
> And to be sure of this you must be able to make everytime a package=20
> ready to run.
There will be... but it _will_ be dependant on others libraries, as all
packages on linux.
>=20
> Sorry to be so long but I would be understood about it. I'm a little=20
Don't say "sorry". Good that you have written all of that, I wanted to
hear it.
> tired to ear "unix is odd job".
I totally agree. But probably because of other reasons :)
> If i'm not mistake, we are actualy 5 linuxmen on this ML. We could test=
=20
> your makefile on different distrib. I'm on MDK 9.0.
> It would be interresting to know on wich distrib we are to help you in=20
> testing your makefile.
It would be great.
Disclaimer: I used all my energy to rethink it, and write this mail, and
don't have any left, to read it from beginig and check, so there may be
errors, and so on ;) I will read it later ;)
--=20
Grzegorz "Silk" Soba=F1ski silk (at) poznan.telbank.pl
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
-- Dave Parnas
|
