[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#138409: [PROPOSAL] Add build environment data to <package>.changes files



>>"Randolph" == Randolph Chung <tausq@debian.org> 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   <srivasta@debian.org>  <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



Reply to: