Ticket #561 (closed enhancement: fixed)
DEB_AUTO_UPDATE_DEBIAN_CONTROL also displeases mortals
| Reported by: | geofft | Owned by: | broder |
|---|---|---|---|
| Priority: | low | Milestone: | Current Semester |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
Nobody can remember what the syntax for manually generating debian/control from debian/control.in is (this is especially confusing to new developers, or non-Debathena folks trying to compile/reuse our code), it's in a number of cases the only thing that makes our version control repository differ from our source packages, and there are a couple of screw cases where [r24514 DEB_AUTO_UPDATE_DEBIAN_CONTROL can't be made to work] even if we wanted to.
We should get rid of our use of DEB_AUTO_UPDATE_DEBIAN_CONTROL/control.in, because it's not buying us all that much compared to the inconsistencies and usability issues it introduces.
For the sake of not patching every package at separate times, Evan wants to do this when #481 and #560 get done.
Change History
comment:2 Changed 14 years ago by broder
No, that was your conclusion. The rest of us have moved on and decided that incremental improvements - especially those which lower the barrier to entry for doing Debathena development - are worth doing, regardless of whether or not they completely and totally solve the underlying problem.
comment:3 Changed 14 years ago by geofft
As you point out, we have in fact discussed this over Email before, and (especially after I changed my mind) I believe we have consensus to move forward with the plan outlined there, of which this ticket is a part. Consensus is not unanimity. A decision has been made per the decision-making policy.
comment:4 Changed 13 years ago by jdreed
- Milestone changed from The Distant Future to Natty Release
So, which packages actually _benefit_ from this? They're mainly in the old Athena tree, right? I assert at this point, even if #334 isn't fixed (I don't understand autogoo enough to look at that), we should turn control.in -> control from any package that has it and doesn't need it. It's not hard for us to say to new developers "Please use regular control files; if you see control.in, it's legacy, and don't duplicate it elsewhere".
comment:5 Changed 13 years ago by jdreed
For some reason I milestoned this for Natty (probably because it'll never get done otherwise). Looking at things, we just need to replace @cdbs@ with cdbs, debhelper, config-package-dev (>= 4.5~), right?
Is there a compelling technical reason not to move forward with this, at least for things under trunk/debathena?
comment:6 Changed 12 years ago by jdreed
Oh, hey, we haven't debated this in a while: "Let's remove control.in from the archive. Go."
We’ve had this discussion N times, and concluded that it’s worth doing if we can also fix #334 (aclocal.m4 is Wrong).