Ticket #561 (closed enhancement: fixed)

Opened 11 years ago

Last modified 8 years ago

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:1 Changed 11 years ago by andersk

We’ve had this discussion N times, and concluded that it’s worth doing if we can also fix #334 (aclocal.m4 is Wrong).

comment:2 Changed 11 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 11 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 10 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 10 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 9 years ago by jdreed

Oh, hey, we haven't debated this in a while: "Let's remove control.in from the archive. Go."

comment:7 Changed 9 years ago by geofft

There's talk of getting rid of CDBS entirely, but I haven't worked on the Debhelper port of config-package-dev recently, so I don't think it's going to get done in bounded time. Go for it.

comment:8 Changed 8 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to fixed

r25887 does this for the debathena tree, r25888 for the athena tree.
r25890 through r25892 fix some unintended changelog changes due to a bug in my scripting.

Note: See TracTickets for help on using tickets.