On Tue, 17 May 2005 12:07:01 -0400, Joey Hess <[EMAIL PROTECTED]> said:
> This "best practice" fails miserably if the maintainer is not always
> perfectly responsive. As soon as the maintainer goes on vacation (or
> MIA) and gets a security hole or RC bug in his package, the more
> nonstandard their packaging the harder it becomes for someone to fix
> the problem in it without introducing other bugs or wasting a lot of
> time stumbling over weirdnesses in its packaging.
> For example, if I need to do a NMU of a package that uses yada or
> debstd, I simply cannot change the behavior of debian/rules since
> these are both too weird/inflexible/hard to use to be
> maintainable. cdbs and dbs also nearly fall into that category, at
> least for me. Hand written rules files do not, but do increase the
> likelyhood of me making some silly mistake.
I find myself agreeing, except that I feel that way as soon as
people get away from tried and tested POSIX commands and
dpkg-dev. There are far more people who are competent with cp,
install, mv, make, and other common POSIX commands, and may not be up
to date with a distribution specific mini helper language. I
appreciate the build system for certain red hat and suse packages not
being arcane and distribution specific when I try and incorporate
changes made in packages on those distributions, and I tend to return
the favour.
Ultimately, this comes down to preferences, and what one is
used to. I would hope that most people are used to cp, mv, install,
make, nad gzip, which is what the vast majority of my rules files are
comprised of.
manoj
--
Luck, that's when preparation and opportunity meet. P.E. Trudeau
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
