Re: Fixing mess involving emacs23, emacs24, and the emacs metapackage
Julien Cristau jcris...@debian.org writes: Really shouldn't use the emacs version as epoch. That's also not what gcc does. Right -- not going to do that. I'm just going to use a sufficiently large native version, i.e. 45.0. So now it looks like I need to upload two changes for emacs23 for wheezy: this change to remove the emacs binary package, and a CVE fix (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684695). So first question -- do you want both changes in the same upload? Second -- do I recall correctly that you'd like to see the emacs-defaults package first, then the emacs23 src package that removes the emacs binary package? Just want to make sure I don't handle things in an order that actually slows you down. 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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipc6x5p2@trouble.defaultvalue.org
Re: Fixing mess involving emacs23, emacs24, and the emacs metapackage
Hi, On Sat, Aug 25, 2012 at 12:05:45PM -0500, Rob Browning wrote: So now it looks like I need to upload two changes for emacs23 for wheezy: this change to remove the emacs binary package, and a CVE fix (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684695). So first question -- do you want both changes in the same upload? yes, that's ok. Second -- do I recall correctly that you'd like to see the emacs-defaults package first, then the emacs23 src package that removes the emacs binary package? It doesn't matter too much if you upload an emacs23 src package with the emacs binary dropped first because emacs has already been taken over by emacs24. And an upload trying to include that binary would be rejected. Also emacs in sid already depends on emacs23. But doing them roughly at the same time makes sense to me. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Fixing mess involving emacs23, emacs24, and the emacs metapackage
On Wed, Aug 8, 2012 at 18:25:28 -0500, Rob Browning wrote: 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. Really shouldn't use the emacs version as epoch. That's also not what gcc does. Cheers, Julien signature.asc Description: Digital signature
Re: Fixing mess involving emacs23, emacs24, and the emacs metapackage
[Added Rob to recipients, as I assumed he's not subscribed]
On 01.08.2012 13:04, Axel Beckert wrote:
Rob Browning wrote:
I made a bit of a mess with respect to the emacs metapackage in
unstable
and wheezy that I'd like to fix.
The problem is that both emacs23 and emacs24 provide the emacs
metapackage,
[...]
One plausible solution would be to just move the emacs metapackage
to
its own emacs-defaults source package (a la gcc-defaults), and so 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}.
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.
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.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/e0c826184155aa7505e7e739c851b...@mail.adsl.funky-badger.org
Re: Fixing mess involving emacs23, emacs24, and the emacs metapackage
Adam D. Barratt a...@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
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871ujhrmon@trouble.defaultvalue.org
Re: Fixing mess involving emacs23, emacs24, and the emacs metapackage
Hi, Rob Browning wrote: I made a bit of a mess with respect to the emacs metapackage in unstable and wheezy that I'd like to fix. The problem is that both emacs23 and emacs24 provide the emacs metapackage, With provide you mean build as in source-package builds binary-package, not as in Provides: emacs, right? (IIRC all the emacs packages do a Provides: emacsen, not a Provides: emacs anyway.) One plausible solution would be to just move the emacs metapackage to its own emacs-defaults source package (a la gcc-defaults), and so 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. 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. Please let me know if that sounds reasonable, or if you have some other way you'd rather handle the problem. Sounds ok for me. (But I'm not part of the release team, I just wanted to have clarified some ambiguous terms.) Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120801120427.ge30...@sym.noone.org
Fixing mess involving emacs23, emacs24, and the emacs metapackage
I made a bit of a mess with respect to the emacs metapackage in unstable and wheezy that I'd like to fix. The problem is that both emacs23 and emacs24 provide the emacs metapackage, and of course, at DebConf, Adam pointed out that as soon as we need updates to emacs23, we'll have a problem. One plausible solution would be to just move the emacs metapackage to its own emacs-defaults source package (a la gcc-defaults), and so 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. This would require two freeze exceptions, one for the updated emacs23 package, and one for the new (trivial) emacs-defaults package. Please let me know if that sounds reasonable, or if you have some other way you'd rather handle the problem. 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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipd7vfrk@trouble.defaultvalue.org
