1 |
On Friday, December 31, 2010 11:16:41 Enrico Weigelt wrote: |
2 |
> * Mike Frysinger <vapier@g.o> schrieb: |
3 |
> > On Thursday, December 30, 2010 01:46:34 Enrico Weigelt wrote: |
4 |
> > > Little example, where I'm working on right now: coreutils and gnulib. |
5 |
> > > Imagine, these jerks not just collected hundreds of (sometimes really |
6 |
> > > broken) tests and workarounds instead of fixing the source - they |
7 |
> > > also collected them in another "package" called gnulib, which gets |
8 |
> > > fetched via git (from the current head instead of some release tag!) |
9 |
> > > and _copied_ into the coreutils source tree by some obscure |
10 |
> > > "bootstrap" script. Wow, self-modifying code. Violating all rules |
11 |
> > > of the very first semester in software engineering ;-o |
12 |
> > |
13 |
> > yeah, once you start fixing Microsoft's runtime library and Solaris' C |
14 |
> > library and old UNIX systems whose owners long died and ........, feel |
15 |
> > free to get gnulib obsoleted. but until that happens, stop living in an |
16 |
> > unrealistic world. gnulib exists for a very real reason and is |
17 |
> > extremely useful to many many people. |
18 |
> |
19 |
> You didn't get my point. I was talking about the way of copying |
20 |
> in (parts of) gnulib into other package's source tree in an |
21 |
> unpredicable way, directly within the build process. |
22 |
|
23 |
i'm guessing you've never actually used gnulib and thus know little about how |
24 |
it works. importation of it isnt "unpredictable" at all. the developer doing |
25 |
the import closely controls what functions exactly they wish to import. |
26 |
|
27 |
> The clean way (tm) would be making it a real library |
28 |
|
29 |
again, clearly you dont follow anything about gnulib. they're already working |
30 |
on an actual shared library now called libposix. |
31 |
|
32 |
> I'm currently in the process of doing exactly that. |
33 |
|
34 |
i'm sure that will totally see real use and isnt a complete waste of time |
35 |
-mike |