Re: Fixing mess involving emacs23, emacs24, and the emacs metapackage
"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> [Added Rob to recipients, as I assumed he's not subscribed]
(Thanks, I'm not.)
>
> On 01.08.2012 13:04, Axel Beckert wrote:
>> Rob Browning wrote:
>>> ... a bit of discussion on IRC produced a plan that I'd like to vet
>>> here:
>>>
>>> - Upload a new emacs23 to for wheezy that doesn't provide the
>>> emacs binary.
>>> - Upload a new emacs-defaults for wheezy that provides the emacs
>>> binary.
>>> - Upload a new emacs24 to unstable that doesn't provide the emacs
>>> binary.
>>
>> With "providing binary", do you mean "building a binary package" or
>> "containing a compiled binary file" as in "/usr/bin/emacs"?
>>
>> The latter would likely break update-alternatives and non-trivial to
>> package, so I suspect you think of the emacs binary-_package_ being
>> built by the new emacs-defaults source-package.
>
> That's what was discussed on IRC, yes. emacs-defaults would be a new
> source package building a single arch:all binary package named
> "emacs", with the same semantics as the existing package of that name
> produced from emacs2{3,4}.
Hmm, (thinking it through...) at least in the most naive approach, the
emacs binary package wouldn't actually contain /usr/bin/emacs, it would
just depend on (for example) "emacs23 | emacs23-nox | emacs23-lucid",
and would leave it up to all of the installed emacs??{,-nox,-lucid}
packages to determine what /usr/bin/emacs actually is (via
update-alternatives).
So if the user had emacs23, emacs24, and emacs installed, /usr/bin/emacs
would be set to /usr/bin/emacs24 because that option has the highest
priority.
Though I suppose there are a number of other variations wrt how the new
"emacs" package could work, each with different semantics, and I don't
think what's described above is how gcc-defaults works.
>> With regards to the version of the emacs-defaults source package (or
>> at least the new emacs binary-package, AFAICS it'll need an epoch
>> added to go down from 24 to 23 again, i.e. use "1:23.$something".
>
> Well, "1:23" would seem to work fine as well, given that it would
> presumably be a native package.
At first, I wondered why the version would matter as long as it's higher
than whatever's currently available in the archive wrt "Package: emacs",
but I suppose it might be aesthetically more pleasing if the emacs
package version matched the emacs version it's recommending.
I suppose we could do what gcc-defaults does, i.e. 4:4.7.1-1, or in this
case 23:*. That might be reasonable.
> Rob - as no-one has raised any objections or other suggestions, I
> think we should move forward with this. Assuming it matches the plan
> as above, please feel free to go ahead with the upload of
> emacs-defaults and let us know once it hits NEW so that we can smile
> nicely at the ftp-team. I'd suggest we get that step sorted out
> before the uploads of emacs2{3,4} dropping the meta-package.
OK, will do, and feel free to shout if I'm doing something wrong, or if
you realize that I should do something differently.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: