Bug#138409: PROPOSAL] Add build environment data to <package>.changes files
> And the bit
> about standards version is a red herring, really: packages are
> supposed to be current with policy (which is why policy froze) -- it
> is just that stable releases have packages that conform to policy as
> it existed then. Packages in Sid need to be current (can't claim
> ancient policy versions in unstable and not fix bugs, for example)
sure eventually all packages will move to the new scheme, and everything
will be happy. i'm not suggesting anything more or less.
> 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
i don't care if it's a separate tool or part of dpkg --build or part of
dpkg-gencontrol. Having policy dictate a specific implementation
methodology is a Bad Idea. This is like saying all internet RFCs need to
have attached implementations.
> 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.
What do you mean by preinstall checks?
The rationale for not including it in the deb (which was how I had it in
my original draft) is that this is not information that is particularly
useful to the general *user* of Debian. changes files have a one-to-one
relationship to a build process, which debs do not have.
> Second, a formal policy proposal is way immature at this
> point. Take this over to -devel, discuss the implementation details,
> talk to dpkg maintainers, and come up with a working prototype of a
> dpkg-gencontrol/dpkg --build (in which case you do not need either a
> transition plan, or even a policy change)
Julian already gave a simple way of doing this.
> Indeed, mandating policy is a far worse way technically than a
> transparent change of the build tool chain.
I will pursue this further with dpkg developers, but I think that is
orthogonal with having it in policy. Why do we put syntax of control
files in the policy, for example, if it is simply a dpkg implementation
detail?
randolph
--
Debian Developer <tausq@debian.org>
http://www.TauSq.org/
Reply to: