>>"Randolph" == Randolph Chung <[EMAIL PROTECTED]> writes:
Randolph> sure eventually all packages will move to the new scheme,
Randolph> and everything will be happy. i'm not suggesting anything
Randolph> more or less.
Then it can't be made mandatory from the word go, if every
single package has to be modified.
Randolph> A new packaging helper tool will be created, hereby refered to as
Randolph> dpkg-buildinfo.
>>
>> Why is this functionality not to be added to dpkg --build? Why
Randolph> i don't care if it's a separate tool or part of dpkg
Randolph> --build or part of dpkg-gencontrol. Having policy dictate a
Randolph> specific implementation methodology is a Bad Idea. This is
Randolph> like saying all internet RFCs need to have attached
Randolph> implementations.
You are missing the point. If this is part of dpkg, we do not
need policy on this. We do not document every little detail in
policy, the document is large and unwieldy enough as it is.
Policy is mostly meant to slect one of a set of technically
equivalent choices in order to help packages cooperate and integrate
into a coherent whole (and thus our desire to have a different
implementations of this cooperation settle down by Darwinian
selection).
>> require all packages to be touched when you can automagically get the
>> desired result by changing the packaging tools? Or perhaps it should
>> be in dpkg-gencontrol? (I don't see why this _has_ to go into the
>> changes file, and not a new file designed for this to facilitate pre
>> install checks). Indeed, having it available for preinstall checks in
>> an automated fashion may be extremely useful once tools are developed
>> to ensure build environment consistency.
Randolph> What do you mean by preinstall checks?
I have a stable system I want all packages on my system to
have been built by a coherent set of packages -- to preclude any
strange interactions between packages built by dofferent versions of
db, for example (yeah, db is a bad example -- but there may be subtle
differences between lib vbersions with the same so name that no one
has caught yet).
`I do a pre-install check -- any package to be installed myst
come built with the same versions of packages all my otehr packages
have.
Randolph> The rationale for not including it in the deb (which was
Randolph> how I had it in my original draft) is that this is not
Randolph> information that is particularly useful to the general
Randolph> *user* of Debian. changes files have a one-to-one
Randolph> relationship to a build process, which debs do not have.
You can't think of a reason that it is useful. That is a whole
different ball game. I canme with one example off the top of my
head. Why restrict future creativity just a use does not come to mind
immediately?
Randolph> I will pursue this further with dpkg developers, but I
Randolph> think that is orthogonal with having it in policy. Why do
Randolph> we put syntax of control files in the policy, for example,
Randolph> if it is simply a dpkg implementation detail?
It is not a dpkg implementation detail Those a re published
interfaces to the packaging system that impact every single darned
package in Debian. They can't just be changed gratituously by the
current or future dpkg developer.
At some point, we should do a complete interface analysis to
allow dpkg alternates to seamlessly drop in into a dpkg managed
system. However, that takes real work in interface definition and
design.
manoj
--
Authors are easy to get on with -- if you're fond of
children. Michael Joseph, "Observer"
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
