Felipe Contreras wrote: > On Sat, Feb 23, 2008 at 10:45 PM, Alec Warner <[EMAIL PROTECTED]> wrote: >> On 2/20/08, Felipe Contreras <[EMAIL PROTECTED]> wrote: >> > b) Error are difficult to handle since bash doesn't have exceptions >> >> I disagree here: most errors are fatal anyway any non fatal errors can >> be printed and saved via the elog facility. > > Yes, for the most common usage that's true, but that think about this > example: I'm compiling gstreamer-plugins-good, which needs libraw1394, > but the compilation fails, perhaps that user is not interested in that > particular plugin so a dialog can pop up and the user can choose if to > continue without the libraw stuff or fail. > That would typically be configured via USE flags, or for some things via a USE expand, like CAMERAS for gphoto. I agree there is scope for UI work, but I think that's better done by other apps calling the package manager, in the same way as other distros do. For Gentoo, we use update from the CLI, and himerge for a GUI, although portato (GTK) and kuroo (KDE) are both nice too. Typically in such an instance a user would see the package fail, and try with a different USE setting.
We're adding USE editing to update, should be done this week; for all the GUIs that's already possible. In terms of what you're discussing, the package manager has to be able to run without user interaction, but a next generation build system is possible (eg pbuilds in python have been discussed on IRC, and qmake et al are around); ebuild is more a meta-format in that it can use a wide variety of base tools. update: http://forums.gentoo.org/viewtopic-t-546828.html http://www.haskell.org/himerge/ http://portato.origo.ethz.ch/ http://kuroo.org/ > I'm sure that can be done without exceptions but as the complexity > increases properly checking/passing around error values/messages > becomes tedious. > >> > c) Persistent information is difficult to achieve (no database stuff) >> >> How is this a bash limitation? Most languages don't have 'database >> stuff' built in. >> I don't see how saving stuff to files is much different than the env >> dumping we do in bash? > > I guess it's mostly the burden of serializing/parsing all that stuff. > Saving to flat files or databases gives the same persistence, and in any case the ebuilds don't mess around with them, the package manager does. It's perfectly possible to use a database to store the information ofc, but at some point you have to deal with the fact that ebuilds are text files edited by humans. >> > A more featured language could allow for example: filtered output, >> > exception handling->state storage->resuming. >> > Portage does all those at the moment (filtering output can easily be done by script, see update, or in an app like kuroo.) >> > But the big deal is with the package definition, recently I learned >> > about Domain Specific Languages, and I think that is the best option. >> > >> > A new dsl allows many interesting features in the package definition >> > itself like: inheritance, exceptions, arrays, hash tables, objects, >> > modules, documentation, information messages, etc. >> >> Note that most languages allow for the same things...so why would we >> author our own language? What runtime would it use? > > The language can be something very simple that has bash embedded. That > has the advantage that you can just copy paste what you are doing > already. > If it's got bash embedded it won't be simple ;) I see ebuilds as already providing that DSL, in that you have full BASH capability and a library of API functions you can use. >> > I've tried different build systems: rpm, dpkg, autopackage. >> > Unfortunately I never tried ebuild because it was based on bash as >> > far as I could tell. >> >> Typically a 'build system' would refer to 'autotools' or 'ant' or >> 'setuptools' not an ebuild. > > Is there such a big difference? > > I'm sure it's possible to by-pass autotools and write down all the > commands required to build something in an ebuild. Similarly it's > possible to use autotools to compile and install a bunch of packages. > You seem to be missing that ebuild is a support metastructure on top of build systems like make, autotools or distutils? > Those "build systems" also need to be updated, but that's another story. > What for? >> > After almost a decade of using Linux I still haven't found a build >> > system that suits all my needs. AFAIK ebuild is the most advanced but >> > it's still relying on ancient technology (bash scripts) so there will >> > always be limitations despite the brilliant ideas. >> >> Bash is not 'ancient' and it works suprisingly well for the vast >> majority of cases. I realize using a high level language would >> probably make some tasks easier (mmm dicts and real arrays). There is >> the matter of porting over 10000 ebuilds however ;) > > Yeah, bash is pretty good for many things, just doesn't scale that much. > I'm not sure where and how it needs to scale. The API provided is very easy to work with and encompasses an amazing range of build systems. > At some point someone decided the current status was not good enough > and decided to create ebuild, even though he was well aware that > thousands of already existing instructions about how to build packages > would have to be re-written. > Not at all; ebuild utilises those instructions (eg makefiles). It just makes every build system available and provides an extended BASH API for common tasks. > If it's easy to write people will possibly even write more of those. > Take for example ArchLinux which also has around 10,000 packages > simply because it's so easy to write them. > Ebuilds are pretty easy too imo. It's perfectly possible to write an ebuild without a single function, for example, if the standard configure --prefix=/usr and make system is in-place (and eclasses extend that to other systems.) > And with something that is distribution agnostic, different > communities can benefit from sharing the same rules. > Ebuilds and portage can be used elsewhere, see http://www.gentoo.org/proj/en/gentoo-alt/prefix/index.xml and in any case Gentoo can be, and is, used as a basis for a binary distro. >> > >> > The core of a distribution is the "packaging" system, and the core of >> > the packaging system is the building system, which has no reason not >> > to be distribution agnostic, and actually, packaging system agnostic. >> > >> > Why not create a new build system with a state of the art programming >> > language, and an advanced DSL that actually other distributions could >> > use? >> I personally don't see the need. -- gentoo-dev@lists.gentoo.org mailing list
