1 |
On 2/24/08, Felipe Contreras <felipe.contreras@×××××.com> wrote: |
2 |
> On Sat, Feb 23, 2008 at 10:45 PM, Alec Warner <antarus@g.o> wrote: |
3 |
> > On 2/20/08, Felipe Contreras <felipe.contreras@×××××.com> wrote: |
4 |
> |
5 |
> > > b) Error are difficult to handle since bash doesn't have exceptions |
6 |
> > |
7 |
> > I disagree here: most errors are fatal anyway any non fatal errors can |
8 |
> > be printed and saved via the elog facility. |
9 |
> |
10 |
> |
11 |
> Yes, for the most common usage that's true, but that think about this |
12 |
> example: I'm compiling gstreamer-plugins-good, which needs libraw1394, |
13 |
> but the compilation fails, perhaps that user is not interested in that |
14 |
> particular plugin so a dialog can pop up and the user can choose if to |
15 |
> continue without the libraw stuff or fail. |
16 |
> |
17 |
> I'm sure that can be done without exceptions but as the complexity |
18 |
> increases properly checking/passing around error values/messages |
19 |
> becomes tedious. |
20 |
|
21 |
This has nothing to do with the build system and everything to do with |
22 |
the package manager actually processing information provided. |
23 |
|
24 |
> |
25 |
> |
26 |
> > > c) Persistent information is difficult to achieve (no database stuff) |
27 |
> > |
28 |
> > How is this a bash limitation? Most languages don't have 'database |
29 |
> > stuff' built in. |
30 |
> > I don't see how saving stuff to files is much different than the env |
31 |
> > dumping we do in bash? |
32 |
> |
33 |
> |
34 |
> I guess it's mostly the burden of serializing/parsing all that stuff. |
35 |
|
36 |
But the code is written already... |
37 |
|
38 |
> |
39 |
> |
40 |
> > > A more featured language could allow for example: filtered output, |
41 |
> > > exception handling->state storage->resuming. |
42 |
> > > |
43 |
> > > But the big deal is with the package definition, recently I learned |
44 |
> > > about Domain Specific Languages, and I think that is the best option. |
45 |
> > > |
46 |
> > > A new dsl allows many interesting features in the package definition |
47 |
> > > itself like: inheritance, exceptions, arrays, hash tables, objects, |
48 |
> > > modules, documentation, information messages, etc. |
49 |
> > |
50 |
> > Note that most languages allow for the same things...so why would we |
51 |
> > author our own language? What runtime would it use? |
52 |
> |
53 |
> |
54 |
> The language can be something very simple that has bash embedded. That |
55 |
> has the advantage that you can just copy paste what you are doing |
56 |
> already. |
57 |
> |
58 |
> As more ideas appear the DSL can be updated, but still, the embedded |
59 |
> bash would always be there. |
60 |
> |
61 |
> <snip/> |
62 |
> |
63 |
> > > This is based on an already working prototype made in Ruby, so it's |
64 |
> > > biased towards Ruby facilities. |
65 |
> > |
66 |
> > It looks Rakish ;) |
67 |
> |
68 |
> |
69 |
> Perhaps, the only interesting thing here is that those commands are |
70 |
> not defined internally. There's an auxiliary bash shell that is |
71 |
> running those commands. Not like "system" calls, which loose the |
72 |
> environment between calls, this is something that cooperates nicely. |
73 |
> |
74 |
> |
75 |
> > > I've tried different build systems: rpm, dpkg, autopackage. |
76 |
> > > Unfortunately I never tried ebuild because it was based on bash as far |
77 |
> > > as I could tell. |
78 |
> > |
79 |
> > Typically a 'build system' would refer to 'autotools' or 'ant' or |
80 |
> > 'setuptools' not an ebuild. |
81 |
> |
82 |
> |
83 |
> Is there such a big difference? |
84 |
> |
85 |
> I'm sure it's possible to by-pass autotools and write down all the |
86 |
> commands required to build something in an ebuild. Similarly it's |
87 |
> possible to use autotools to compile and install a bunch of packages. |
88 |
> |
89 |
> Those "build systems" also need to be updated, but that's another story. |
90 |
|
91 |
Updating for the sake of 'stuff being old' is not a compelling case. |
92 |
|
93 |
> |
94 |
> |
95 |
> > > After almost a decade of using Linux I still haven't found a build |
96 |
> > > system that suits all my needs. AFAIK ebuild is the most advanced but |
97 |
> > > it's still relying on ancient technology (bash scripts) so there will |
98 |
> > > always be limitations despite the brilliant ideas. |
99 |
> > |
100 |
> > Bash is not 'ancient' and it works suprisingly well for the vast |
101 |
> > majority of cases. I realize using a high level language would |
102 |
> > probably make some tasks easier (mmm dicts and real arrays). There is |
103 |
> > the matter of porting over 10000 ebuilds however ;) |
104 |
> |
105 |
> |
106 |
> Yeah, bash is pretty good for many things, just doesn't scale that much. |
107 |
> |
108 |
> At some point someone decided the current status was not good enough |
109 |
> and decided to create ebuild, even though he was well aware that |
110 |
> thousands of already existing instructions about how to build packages |
111 |
> would have to be re-written. |
112 |
> |
113 |
> If it's easy to write people will possibly even write more of those. |
114 |
> Take for example ArchLinux which also has around 10,000 packages |
115 |
> simply because it's so easy to write them. |
116 |
> |
117 |
> And with something that is distribution agnostic, different |
118 |
> communities can benefit from sharing the same rules. |
119 |
|
120 |
What is 'distribution agnostic'? |
121 |
|
122 |
Technically most things are; rpm is used by many distros and is |
123 |
basically similar to what we have (phases, a meta language used to |
124 |
move files around, bad dependencies). So is a debian rules file. How |
125 |
are these 'distro specific'? |
126 |
|
127 |
> |
128 |
> |
129 |
> > > |
130 |
> > > The core of a distribution is the "packaging" system, and the core of |
131 |
> > > the packaging system is the building system, which has no reason not |
132 |
> > > to be distribution agnostic, and actually, packaging system agnostic. |
133 |
> > > |
134 |
> > > Why not create a new build system with a state of the art programming |
135 |
> > > language, and an advanced DSL that actually other distributions could |
136 |
> > > use? |
137 |
> > |
138 |
> > I would talk to Drobbins, he was talking about something like this to |
139 |
> > manage complexity. |
140 |
> |
141 |
> |
142 |
> Will do. |
143 |
|
144 |
So the biggest problem I see here is that this all seems like academic |
145 |
handwaving. You don't move from an established yet complex format |
146 |
like ebuild to some other random format that no one has ever used |
147 |
before. Someone needs to come up with something, foster it, get 500 |
148 |
packages written that use it with a package manager that can actually |
149 |
install them.. Spell out the advantages of why the new format kicks |
150 |
ass and what it gives over the others (rpm, ebuild, deb, others...) |
151 |
and then maybe people will move. |
152 |
|
153 |
I would posit that most developers don't care because ebuild works for |
154 |
them and there exists a small percentage of packages that could |
155 |
benefit from a better system. |
156 |
|
157 |
> |
158 |
> Best regards. |
159 |
> |
160 |
> |
161 |
> -- |
162 |
> |
163 |
> Felipe Contreras |
164 |
> -- |
165 |
> gentoo-dev@l.g.o mailing list |
166 |
> |
167 |
> |
168 |
-- |
169 |
gentoo-dev@l.g.o mailing list |