On Thursday 19 May 2005 06:40, Manoj Srivastava wrote: > On Thu, 19 May 2005 00:29:03 +0200, cobaco (aka Bart Cornelis) <[EMAIL PROTECTED]> said: > > On Wednesday 18 May 2005 08:06, Manoj Srivastava wrote:
> -> so you're right back to distribution specific knowledge being
> -> needed anyhow
>
> No. Distribution knowledge is required to build for inclusion
> in debian -- but modifying a debian package build system, or building
> a debian package on another system (which I have done in the past)
> requires no distribution specific skills.
fair enough
> As for Debian developers, I would think that knowledge of
> policy and best practices is the very least of what one should
> expect. I mean, if I am not even conversant with packaging policy,
> why am I more than just a glorified packager?
being conversant in packaging policy and knowing every little detail by hard
are two very different things, the latter is necessary to get things right
all the time when you recode everything yourself every time.
> My expectation of a developer is not only someone who knows what debian
> packaging entails, but some one also involved in expanding the state of
> the art in that area, and helping with better integration, and actively
> involved in making the OS seamlessly integrate the component
> packages.
ideally that'd be the case, but that vision doesn't seem to be correspond to
reality at the moment, at least in my experience: there seem to be plenty
of DDs only caring about their own packages (fortunately there are plenty
DDs that do care about the larger picture to)
> Yes, I am quite familiar with the helper-packages-as-a-crutch
> argument.
why do you see using helper packages (essentially code libraries) as using a
crutch? avoiding duplication of effort and code is a Good Thing no?
> I am also of the opinion that the growing adherence to this
> view would lead to the decline of packaging in Debian in the long
> run.
you'd expect improved code-reuse to lead to more bugs? I'd expect the
opposite to be the case.
Note: Given the relatively easy things debhelper scripts do I don't think it
will solve any of the hard bugs but it will prevent a lot of little ones
that will slip in when people absentmindedly forget some litle detail
Also I sea use of debhelper (or any other library of code-snippets) as
completely orthogonal to understanding policy:
The NM process is supposed to ensure DD's have an adequate knowledge of
policy (amongst other things) no?
So if the NM-process works as expected, any DD should have an adequate
understanding of policy, and in that case I don't see how pushing for
increased code-reuse does anything but help. (NOTE: I said push, not force,
it remains rightfully the maintainers choice,)
I simply don't get why one would regard somebody pushing for increased
code-reuse as being pointlessly irritating, or as attacking your judgment
and skills (both views which people have expressed in this thread)
> Policy is not writ in stone, ya know.
exactly, so lets do a theoretical exercise:
policy specifies that installed documentation should be 'gzip -9'-ed when
not small, now suppose that at some point we decide to mandate use of bzip
-9 instead
- with debhelper, you change it once, and everything (using debhelper) will
automatically adapt on the next build -> painless transition
- with everyone using their own hand-crafted bits of code, you know have to
contact all DD's, and then wait for each of them to get around to changing
their code -> more people need to make the same change (waste of effort),
and somebody will have to spend effort prodding those who'd forget, missed
the bulletin, or are simply busy with more important stuff
> An informed developer community, that actually thinks about the whys and
> wherefores of policy and best practices, rather than blindly toeing
> whatever line the automated tools tell one to toe, is a far better thing
> for debian.
IMO somebody pushing for increased code-reuse (wether through debhelper or
something else) _is_ thinking about the general picture and pushing for
best practices.
People doing things blindly is always a bad thing off course, but that's an
unrelated (or at least a not directly related) issue.
> > hm, If you do this often it's a net loss: instead of studying one
> > piece of code once to figure out what it does, you now have to study
> > n pieces of code all doing essentially the same thing for n packages
>
> None of this is rocket sceince. I doubt that much âstudyâ
> involved.
true, none of this is complicated code, but then the same is true for
debhelper:
-> so this is definately a weak argument,
-> I'd expect time and effort savings (or costs, depending on your view) of
using debhelper to be pretty much ignorable either way for a single
developer
It's when looking at the accumulated costs over all DD's when using
hand-crafted vs. standard code-snippets that I see a gain being made using
standard code-snippets (wheter those standard code snippets should be
debhelper's perl, or some alternative using only POSIX commands is a
different issue).
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
pgptrJNBcdD1f.pgp
Description: PGP signature
