<oriansj>mihi: well having a documented and stable ABI is both a good and bad thing, depending on your goals. <oriansj>for example if your libc is part of your operating system and you have the belief that people should be building from source and not using binary files, then it is a simple way to ensure binaries break on every updated version <oriansj>if your goal is to encourage a large library of software that works regardless of the changes in your kernel, then having a documented and stable ABI is a very good thing. Otherwise could you imagine trying to get all of the third party libc to use the new syscall numbers with each new release... <stikonas>fossy: hmm, I think I now find --external-sources (or at least description of it) a bit confusing <stikonas>it might not be immediately clear whether we are downloading or using cache ***attila_lendvai_ is now known as attila_lendvai
<fossy>stikonas: hmm, do you mean by the wording? <stikonas>fossy: well, I mean we should be more clear whether --external-sources downloads stuff before bootstrap <stikonas>possibly just be more explicit in --help message <stikonas>fossy: and on the different note, I'm making autotools more explicit, so that we run e.g. autoconf-2.64 rather than autoconf and then I'll remove those symlinks autoconf->autoconf-* <stikonas>though maybe not for the latest autoconf <stikonas>fossy: oh also another question. Do you think it's worth specifying package dependencies explicitly and then writing dependency resolver? So that e.g. build_all package will run all require build steps? <stikonas>after coreutils that should be fairly simple <fossy>do you mean that build_all xyz would also build all packages it needs to build itself? <stikonas>and that last point (dependency resolver) I'm not yet sure if we want or not <stikonas>e.g. if you order let's say build of binutils-2.14, it will first build it's dependencies, before that autoconf-2.12 libtool-1.4 automake-1.4-p6... <stikonas>or is it better to keep everything explicit <stikonas>i.e. if we put DEPS="..." variable in those build scripts it might be possible to figure out the order in which packages have to be built <fossy>i'll have to give that one some thought <fossy>i'm not certain of the usecase for that - it would be a ncie-to-have in terms of build ordering but then again i do like the really transparent and visible nature of the builds <stikonas>it might be useful if we add extra optional packages (or maybe some distro bootstrapping branches) <stikonas>it's either transparent boot ordering or a bit more explicit dependencies <stikonas>again I'm not necesserily saying that we should switch to it <stikonas>I'm not sure myself, but some discussion might be useful <fossy>yeah, it would be useful for distro bootstrapping branches <fossy>although, those would all build on some common base, and we're not quite up to that yet ***kitzman_ is now known as kitzman
***civodul` is now known as civodul