Re: Policy progress
On Tue, 02 Sep 2003 23:20:21 +0200, Stefan Gybas <sgybas@debian.org> said:
> Manoj Srivastava wrote:
>> I would not want this to change. Anyone can make innovative
>> proposals, but the hard part is getting things to work -- and just
>> doing it. Debhelper, debconf, the whole testing distribution --
>> were all proposed, and worked on, without first getting policy to
>> bless them.
> Yes, these are good examples for changes which don't need Policy's
> blessing, e.g. you just need to convince the FTP admins if you want
> to implement testing. However there are also a lot of counter
> examples of features which need to be prescribed by Policy before
> they get implemented.
> Two of these examples are MD5 sums and package signatures. Policy
> still does not require packages to provide MD5 sums for all files in
> the package.
Read the discussions about this topic. The results of
previous discussions has been that this is bezt implemented in dpkg,
and there is an option in debsums how you can hook this into dpkg on
the local machine.
> However, most of the packages on my system do provide
> /var/lib/dpkg/info/*.md5sums but I still can't verify the integrity
> of my system because a few packages don't provide them and so
Does the DPkg::Post-Invoke hook method not work? Indeed, this is
a prime example of why things should not be codified in policy before
we have worked the kinks out -- often, the best solution evolves as
the solutions are deployed, and we should refrain from prematurely
recommending a design, and thus shutting out better implementations.
> package signatures can't be added. The technology is there, it is
> working well> -- it's just not required by Policy. Adamantix has
> shown that it can be done now without waiting for the dpkg
> developers to implement it directly in dpkg.
Are you not mixing md5sums and signatures here? Package
signatures, again, should be added to dpkg -- and need to be added in
a fashion that older versions of dpkg do not barf on them. Is the
technology you claim to be "working well" take care of backwards
compatibility? Does it take care of not having katie and friends
choke on the package?
If not, again, this is a reason we should not encode solutions
in policy before their time.
>> I see. debconf, debhelper, testing, the whole new bts system
>> -- not innovative, just because they do not fit into your theory?
> I was talking about innovations that are visible to the end user, so
> I've indeed forgotten debconf. debhelper is surely older than 4
> years, I remember that I've switched my first package from debstd to
> debhelper in 1998.
And yet, still not mandated by policy. Hmm.
>> I see. Unless we can use policy to beat developers on the head with
>> RC bugs, we are stuck. (Never mind that RC bugs are not determined
>> by policy, but hey).
> Come on, be serious. Just because a package is not Policy compliant
> doesn't mean that the maintainer will be hurt.
I am being serious. And you are being much too literal about
the phrase beating people on the head.
> For example, the latest Policy change that Build-Depends-Indep need
> not be satisfied during clean caused a bit of work for most Java
> maintainers. Almost all Java packages are architecure independent so
> they only had Build-Depends-Indep in debian/control. Now we also
> need to add Build-Depends since at least debhelper is called in the
> clean target. Did it hurt? Did we complain? We just changed our
> packages (or will do so in the next upload). According to your
> strategy, this change would not have been allowed.
But the problem existed before the policy change: the build
daemons did not satisfy Build-Depends-Indep in the clean target;
policy was merely being brought into line with existing reality.
> I thought that if a package violates a "must" requirement in the
> Policy the bug will be RC. So yes, Policy determines the severity of
> bugs.
Then you should go and read the release managers mail to
d-d-a, which delineates exactly what is release critical.
>>> Therefore I suggest to accept changes to the Policy even if this
>>> means that some packages suddenly violate the Policy. This of
>>> course only makes sense when the required infrastructure (e.g. a
>>> features in dpkg) is already there and the proposed change has
>>> proven to work correctly in other packages (reference
>>> implementation).
>> I think this is a stunningly bad idea, for reasons I have already
>> extolled.
> Could you please explain them again? The only one that I've found is
> that you don't want to beat developers with RC bugs. The bugs won't
> be RC if the packages are violating a "should" requirement.
Well, a policy change can't make a whole lot of packages
instantly buggy.. This is good practicew for policies, and even more
so since this mailing list has no constitutional power to change the
policy in a away that causes a whole lot of work to be done by other
developers.
So you should not beat developers on the head with bugs just
to make them do things they may not agree with -- just by changing
policy out from under them.
>> Well, if you cannot convince the people who do the work, no, it
>> shall not get done. If the idea is so good, why would it be so
>> hard to convince the developers who maintain the packages that it
>> is a good idea?
> Because there's always someone who disagrees. Even if 99% of all
> developers agree, at last one of the 10 remaining developers will
> formally object. :-(
So what? We have a means of voting changes into policy. Call
on the tech ctte. Or pass a GR. The policy group only changes policy
by achieving a rough consensus.
> If you want to rely on a feature like the status option for init
> script (or MD5 sums), it needs to be implemented in all relevant
> packages. It gains us nothing if I can convince 75% of the
> developers.
If you convince most of the developers, or you can handle the
technical objections raised, or demonstrate the solution provided is
indeed optimal (like, why shouldn't dpkg create the md5sums on
install, as wiggy has been arguing is the best method), you can too
get a policy change started.
You want fater changes, then I am afraid you need to start
talking about changing the constitution to allow an self selected
subset of developers the right to change Debian Technical Policy in a
fashion that overrules individual developers.
manoj
--
The 357.73 Theory: Auditors always reject expense accounts with a
bottom line divisible by 5.
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: