Re: Feaping Creature-ism in core Debian Packages
On 31-Aug-99, 08:09 (CDT), Dale Scheetz <firstname.lastname@example.org> wrote:
> It would be a better design if no package that used debhelper would fail
> to build without the existance of debhelper. I see no reason that these
> helper programs can't construct a self-contained rules file with none of
> the external calls now present.
Because then fixing/changing/updating the helper program doesn't do
likewise to the rules file. It's the same reason that you make a
subroutine for anything you do more than once -- maintenance is made
much easier (Yeah, I realize the situations are not 100% analogous --
it's more like shared libraries vs. static libs.)
> My only objection to this package is that
> it automatically makes the rules file depend on the existance of the
> debhelper package. This makes the package defacto important rather than
> the optional that officially holds as a priority.
Nitpick extreme: standard rather than important (make, gcc, etc. are all
> [changing interfaces in perl]
> While the same things can be said about glibc, I don't think this implies
> that we should treat perl in the same fashion that we do glibc.
Why not? If changing interfaces are not bad in glibc, they why are they
bad in perl? Conversly, if they are bad in perl, why not complain about
glibc too? (I know the answer: we can't do with a C library, but we
could struggle along without perl. But that feels like a copout, some
IMO, perl has become just as much a part of "standard" unix (or at least
Linux) as bash, awk, and sed. The painful upgrade from 5.004 to 5.005
was primarily due to the creation of a mechanism to allow multiple
versions of perl on the machine, just as a long time ago we figured out
how to have multiple versions of libc on the machine, for much the same
reason. Future upgrades should be straight forward.
FWIW, I'm strongly considering ripping all the debhelper stuff out of
my rules files, for some of the reasons you mention in a later posting:
lack of control and complete understanding of what it's doing.