1 |
* Kfir Lavi <lavi.kfir@×××××.com> schrieb: |
2 |
|
3 |
> Well, you are a purist ;-) |
4 |
|
5 |
At this point, yes ;-p |
6 |
|
7 |
> The thing is, I must use this ACE libs, and they are broken. |
8 |
> I have also so many other things to get working, I just have to live with |
9 |
> this approach. |
10 |
|
11 |
Yep, I know lots of those situations where you have to get the |
12 |
job done, but stumble across dozens of problems which would |
13 |
have been prevented by proper development methods and workflows. |
14 |
|
15 |
Just experiencing that at my current customer, where they don't |
16 |
even have a proper vcs (TFS is even more insane than SVN ;-o) |
17 |
|
18 |
> Your method regenerating the ./configure script, is very good, |
19 |
|
20 |
And often it's necessary, when you have the configure.in stuff. |
21 |
|
22 |
> and I'm asking myself, why its not done every install, or why we |
23 |
> get ./configure generated in the tar.gz. |
24 |
|
25 |
These arguments I've heared over the years: |
26 |
|
27 |
a) save time and cpu cycles for end users |
28 |
b) get around autotools version conflicts |
29 |
c) we always did so, so why change ? |
30 |
|
31 |
I dont buy any of them. There're better solutions. |
32 |
|
33 |
The best solution, IMHO, would be replacing all these dubious macros |
34 |
by a bunch of carefully written shell functions. Something like |
35 |
|
36 |
AC_CHECK_HEADER([foo.h],[do-something-if-found],[do-someting-if-not-found]) |
37 |
|
38 |
could be easily replaced by: |
39 |
|
40 |
if ac_check_header foo.h ; then |
41 |
do-something-if-found |
42 |
else |
43 |
do-something-if-not-found |
44 |
fi |
45 |
|
46 |
There would be no generation phase at all. |
47 |
|
48 |
|
49 |
I've started some hacking on that for zlib, a while ago. Maybe |
50 |
somebody might like to join me ... |
51 |
|
52 |
> > I'm even going farer: if upstream has an proper vcs, I take the |
53 |
> > releases from there, completely regenerating everything from |
54 |
> > scratch. All fixes are done within my VCS (essentially, I always |
55 |
> > have my own releases ontop the upstream's, as git tags). Sometimes |
56 |
> > you encounter packages, eg. coreutils, which doing really messy |
57 |
> > things like pulling in another tree via git and copying in files |
58 |
> > from there - a nightmare for packagers ;-o |
59 |
> > |
60 |
> > I wonder, do you patch every ebuild to do just that? |
61 |
> |
62 |
> Maybe there should be a new FEATURE that request the ebuild to download the |
63 |
> release from the VCS. |
64 |
|
65 |
That probably multiplies the QM load to the ebuild maintainers, |
66 |
as they would have to maintain different versions with the same |
67 |
version number. And the benefit is questionable. |
68 |
|
69 |
I'd rather propose (on per-package basis) directly maintain the sources |
70 |
(including dist-specific changes) in an own repository, so the whole |
71 |
download+unpack+patch phase is replaced by just a checkout, and things |
72 |
like rebasing dist-specific changes can be done directly via vcs. |
73 |
|
74 |
These repositories can now also be used easily by other folks, |
75 |
distros can monitor and share their changes easily. |
76 |
|
77 |
http://www.metux.de/download/oss-qm/normalized_repository.pdf |
78 |
|
79 |
|
80 |
cu |
81 |
-- |
82 |
---------------------------------------------------------------------- |
83 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
84 |
|
85 |
phone: +49 36207 519931 email: weigelt@×××××.de |
86 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
87 |
---------------------------------------------------------------------- |
88 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
89 |
---------------------------------------------------------------------- |