* Kfir Lavi <[email protected]> schrieb:
> Well, you are a purist ;-)
At this point, yes ;-p
> The thing is, I must use this ACE libs, and they are broken.
> I have also so many other things to get working, I just have to live with
> this approach.
Yep, I know lots of those situations where you have to get the
job done, but stumble across dozens of problems which would
have been prevented by proper development methods and workflows.
Just experiencing that at my current customer, where they don't
even have a proper vcs (TFS is even more insane than SVN ;-o)
> Your method regenerating the ./configure script, is very good,
And often it's necessary, when you have the configure.in stuff.
> and I'm asking myself, why its not done every install, or why we
> get ./configure generated in the tar.gz.
These arguments I've heared over the years:
a) save time and cpu cycles for end users
b) get around autotools version conflicts
c) we always did so, so why change ?
I dont buy any of them. There're better solutions.
The best solution, IMHO, would be replacing all these dubious macros
by a bunch of carefully written shell functions. Something like
AC_CHECK_HEADER([foo.h],[do-something-if-found],[do-someting-if-not-found])
could be easily replaced by:
if ac_check_header foo.h ; then
do-something-if-found
else
do-something-if-not-found
fi
There would be no generation phase at all.
I've started some hacking on that for zlib, a while ago. Maybe
somebody might like to join me ...
> > I'm even going farer: if upstream has an proper vcs, I take the
> > releases from there, completely regenerating everything from
> > scratch. All fixes are done within my VCS (essentially, I always
> > have my own releases ontop the upstream's, as git tags). Sometimes
> > you encounter packages, eg. coreutils, which doing really messy
> > things like pulling in another tree via git and copying in files
> > from there - a nightmare for packagers ;-o
> >
> > I wonder, do you patch every ebuild to do just that?
>
> Maybe there should be a new FEATURE that request the ebuild to download the
> release from the VCS.
That probably multiplies the QM load to the ebuild maintainers,
as they would have to maintain different versions with the same
version number. And the benefit is questionable.
I'd rather propose (on per-package basis) directly maintain the sources
(including dist-specific changes) in an own repository, so the whole
download+unpack+patch phase is replaced by just a checkout, and things
like rebasing dist-specific changes can be done directly via vcs.
These repositories can now also be used easily by other folks,
distros can monitor and share their changes easily.
http://www.metux.de/download/oss-qm/normalized_repository.pdf
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: [email protected]
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
