unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Version naming
@ 2014-09-29 17:19 Stefan Monnier
  2014-09-30  4:55 ` Drew Adams
                   ` (3 more replies)
  0 siblings, 4 replies; 29+ messages in thread
From: Stefan Monnier @ 2014-09-29 17:19 UTC (permalink / raw)
  To: emacs-devel

OK, here's one of the favorite discussion topics.

So I'll keep it short to get the discussion started:

   The next release from trunk will be called 25.1 rather than 24.5

There, I said it.  For completeness, here's the motivation:
In retrospect 24.3 should have been named 25.1 and 24.4 should have been
named 26.1.  The ".N" thingy should really be kept only for bug-fix
releases and neither of 24.3, 24.4, nor the previously planned 24.5 are
bug-fix releases.

I'll stop listening to this thread starting right about now, but don't
let that stop you wasting your time debating at length about this boring
subject,


        Stefan



^ permalink raw reply	[flat|nested] 29+ messages in thread

* RE: Version naming
  2014-09-29 17:19 Version naming Stefan Monnier
@ 2014-09-30  4:55 ` Drew Adams
  2014-09-30  7:03 ` Thien-Thi Nguyen
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 29+ messages in thread
From: Drew Adams @ 2014-09-30  4:55 UTC (permalink / raw)
  To: Stefan Monnier, emacs-devel

> 24.4 should have been named 26.1.

"Should have been"?  24.4 does not yet exist - it has not been
released.

The baby is not born.  Why regret having in mind the wrong
name?  It is still gestating, with a shipload of regressions
and other bugs.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-09-29 17:19 Version naming Stefan Monnier
  2014-09-30  4:55 ` Drew Adams
@ 2014-09-30  7:03 ` Thien-Thi Nguyen
  2014-10-10  7:58   ` Thien-Thi Nguyen
  2014-09-30 14:13 ` Lars Magne Ingebrigtsen
  2014-10-12 22:27 ` Jens K. Loewe
  3 siblings, 1 reply; 29+ messages in thread
From: Thien-Thi Nguyen @ 2014-09-30  7:03 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Mon, 29 Sep 2014 13:19:08 -0400

   So I'll keep it short to get the discussion started:

      The next release from trunk will be called 25.1 rather than 24.5

Cool.

   There, I said it.  For completeness, here's the motivation: In
   retrospect 24.3 should have been named 25.1 and 24.4 should
   have been named 26.1.  The ".N" thingy should really be kept
   only for bug-fix releases and neither of 24.3, 24.4, nor the
   previously planned 24.5 are bug-fix releases.

You should write all this in admin/notes/versioning, or somesuch.
That way, the need (or rather, people's desire) for this...

   I'll stop listening to this thread starting right about now,
   but don't let that stop you wasting your time debating at
   length about this boring subject,

...can be much reduced.  A repo'd document also has the advantage
of providing an evolvable base for attaching labels (such as
"stable", "bugfix", etc), the most likely-to-succeed way out of
the next rat's nest (i.e., preferred/"official" Emacs-under-Git
branch discipline/manglement/workflow) discussion.  Just watch!

I say "you should" as a shorthand for "we should, and i (in my own
crass and clumsy way) will do so RSN if someone who has more
impact doesn't beat me to it".  (In this case, RSN == one week.)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-09-29 17:19 Version naming Stefan Monnier
  2014-09-30  4:55 ` Drew Adams
  2014-09-30  7:03 ` Thien-Thi Nguyen
@ 2014-09-30 14:13 ` Lars Magne Ingebrigtsen
  2014-09-30 14:17   ` Ted Zlatanov
  2014-10-15 22:42   ` Rob Browning
  2014-10-12 22:27 ` Jens K. Loewe
  3 siblings, 2 replies; 29+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-09-30 14:13 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> OK, here's one of the favorite discussion topics.
>
> So I'll keep it short to get the discussion started:
>
>    The next release from trunk will be called 25.1 rather than 24.5
>
> There, I said it.  For completeness, here's the motivation:
> In retrospect 24.3 should have been named 25.1 and 24.4 should have been
> named 26.1.  The ".N" thingy should really be kept only for bug-fix
> releases and neither of 24.3, 24.4, nor the previously planned 24.5 are
> bug-fix releases.

That's a bit like the naming scheme Emacs had between version 1 and 18,
isn't it?

The numbering doesn't really matter, but I think it was kinda nice when
the major version number was only bumped on really big-ish transitions.
(I.e., mule, utf8, static binding...)

But, of course, the next Emacs release has eww, and that's a major
thing.  >"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-09-30 14:13 ` Lars Magne Ingebrigtsen
@ 2014-09-30 14:17   ` Ted Zlatanov
  2014-10-15 22:42   ` Rob Browning
  1 sibling, 0 replies; 29+ messages in thread
From: Ted Zlatanov @ 2014-09-30 14:17 UTC (permalink / raw)
  To: emacs-devel

On Tue, 30 Sep 2014 16:13:40 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> But, of course, the next Emacs release has eww, and that's a major
LMI> thing.  >"?

"Emacs Web Edition"

Ted




^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-09-30  7:03 ` Thien-Thi Nguyen
@ 2014-10-10  7:58   ` Thien-Thi Nguyen
  2014-10-11  0:28     ` Glenn Morris
  0 siblings, 1 reply; 29+ messages in thread
From: Thien-Thi Nguyen @ 2014-10-10  7:58 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

() Thien-Thi Nguyen <ttn@gnu.org>
() Tue, 30 Sep 2014 09:03:12 +0200

   shorthand for [...] RSN

I've just added admin/versioning.
I hope people will refine it.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-10  7:58   ` Thien-Thi Nguyen
@ 2014-10-11  0:28     ` Glenn Morris
  2014-10-11 11:18       ` Thien-Thi Nguyen
  0 siblings, 1 reply; 29+ messages in thread
From: Glenn Morris @ 2014-10-11  0:28 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: emacs-devel

Thien-Thi Nguyen wrote:

> () Thien-Thi Nguyen <ttn@gnu.org>
> () Tue, 30 Sep 2014 09:03:12 +0200
>
>    shorthand for [...] RSN
>
> I've just added admin/versioning.

I don't really know what the point of that is. Who is it for?
Also it seems a rather long-winded, unclear summary of what Stefan said,
which boils down to:

   the ".N" thingy should really be kept only for bug-fix releases



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-11  0:28     ` Glenn Morris
@ 2014-10-11 11:18       ` Thien-Thi Nguyen
  2014-10-15  7:13         ` Glenn Morris
  0 siblings, 1 reply; 29+ messages in thread
From: Thien-Thi Nguyen @ 2014-10-11 11:18 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

() Glenn Morris <rgm@gnu.org>
() Fri, 10 Oct 2014 20:28:32 -0400

   Who is it for?

It's for anyone who would rather write this kind of stuff:
         
      the ".N" thingy should really be kept only for bug-fix
      releases

down than discuss (or watch discussed) the matter at length
(and often circularly) on mailing lists.  Maybe i stand alone
in this set, but i doubt it.

It's also for Org Mode hackers, as another "test document".
Granted, it doesn't exercise much of Org Mode at the moment,
but who knows what coolness may arise given the opportunity.
(A cursory M-x find-grep doesn't reveal other Org Mode files
under admin/, so i might be missing something.)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-09-29 17:19 Version naming Stefan Monnier
                   ` (2 preceding siblings ...)
  2014-09-30 14:13 ` Lars Magne Ingebrigtsen
@ 2014-10-12 22:27 ` Jens K. Loewe
  3 siblings, 0 replies; 29+ messages in thread
From: Jens K. Loewe @ 2014-10-12 22:27 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier schrob am 29. Sep. 2014 um 13:19 Uhr dies:

> There, I said it.  For completeness, here's the motivation:
> In retrospect 24.3 should have been named 25.1 and 24.4 should have been
> named 26.1.  The ".N" thingy should really be kept only for bug-fix
> releases and neither of 24.3, 24.4, nor the previously planned 24.5 are
> bug-fix releases.

Looking forward to Emacs 72 by the end of 2015.


-- 
I could contain traces of nuts.




^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-11 11:18       ` Thien-Thi Nguyen
@ 2014-10-15  7:13         ` Glenn Morris
  2014-10-15 10:46           ` Thien-Thi Nguyen
  0 siblings, 1 reply; 29+ messages in thread
From: Glenn Morris @ 2014-10-15  7:13 UTC (permalink / raw)
  To: emacs-devel


Sorry, I found it hard to read, so I rewrote it to be prosaic.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-15  7:13         ` Glenn Morris
@ 2014-10-15 10:46           ` Thien-Thi Nguyen
  0 siblings, 0 replies; 29+ messages in thread
From: Thien-Thi Nguyen @ 2014-10-15 10:46 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

() Glenn Morris <rgm@gnu.org>
() Wed, 15 Oct 2014 03:13:40 -0400

   Sorry, I found it hard to read, so I rewrote it to be prosaic.

No worries -- looks good.  Thanks.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-09-30 14:13 ` Lars Magne Ingebrigtsen
  2014-09-30 14:17   ` Ted Zlatanov
@ 2014-10-15 22:42   ` Rob Browning
  2014-10-16  2:47     ` Stefan Monnier
  1 sibling, 1 reply; 29+ messages in thread
From: Rob Browning @ 2014-10-15 22:42 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen, Stefan Monnier; +Cc: emacs-devel

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The numbering doesn't really matter, but I think it was kinda nice when
> the major version number was only bumped on really big-ish transitions.
> (I.e., mule, utf8, static binding...)

That's how we've taken it in Debian at least (and derivatives), which
has allowed simultaneous installs (say emacs19 and emacs20), etc.

As a result, on the Debian side, each major increment does represent
more work: increased load on the mirrors, administrative overhead of
package migrations, removals, etc.

While that certainly shouldn't unduly influence the upstream decisions
here, I thought I'd mention it for reference.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-15 22:42   ` Rob Browning
@ 2014-10-16  2:47     ` Stefan Monnier
  2014-10-16  6:10       ` Stephen J. Turnbull
  2014-10-16 13:51       ` Barry Warsaw
  0 siblings, 2 replies; 29+ messages in thread
From: Stefan Monnier @ 2014-10-16  2:47 UTC (permalink / raw)
  To: Rob Browning; +Cc: Lars Magne Ingebrigtsen, emacs-devel

> As a result, on the Debian side, each major increment does represent
> more work: increased load on the mirrors, administrative overhead of
> package migrations, removals, etc.

The real underlying cause is dpkg's inability to handle simultaneous
installs of different versions of the same package.  As a result, you
get more work, as you point out, and I can't easily keep around all the
versions I'd like to keep.


        Stefan



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-16  2:47     ` Stefan Monnier
@ 2014-10-16  6:10       ` Stephen J. Turnbull
  2014-10-16 13:51       ` Barry Warsaw
  1 sibling, 0 replies; 29+ messages in thread
From: Stephen J. Turnbull @ 2014-10-16  6:10 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier writes:

 > The real underlying cause is dpkg's inability to handle simultaneous
 > installs of different versions of the same package.  As a result, you
 > get more work, as you point out, and I can't easily keep around all the
 > versions I'd like to keep.

I don't know if Debian would be willing to make official packages with
relocatable installations (ie, /opt-style installation aka application
bundle) but that would help solve the problem (up to conflicting
external dependencies, but I doubt Emacs has many "must equal x.YY"
dependencies).  I don't do it any more (running in-place is easier)
but I did experiment with it successfully a while back for locally
created dpkgs of XEmacs.

The idea is basically that you can have a complete set of
{bin,etc,lib,man,share} trees under /opt/local/emacs-x.yy (ie, the
arch-dependent files would end up in
/opt/local/emacs-x.yy/lib/emacs-x.yy/x86_64-pc-gnu-linux/ or similar),
which is pretty redundant, but means that the versions don't compete
for the same file names in arch-independent hierarchies.

For more information about how this is managed, ask Mike Sperber about
--with-prefix=no.  I don't know the details.









^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-16  2:47     ` Stefan Monnier
  2014-10-16  6:10       ` Stephen J. Turnbull
@ 2014-10-16 13:51       ` Barry Warsaw
  2014-10-16 17:19         ` Rob Browning
  2014-10-16 20:01         ` Stefan Monnier
  1 sibling, 2 replies; 29+ messages in thread
From: Barry Warsaw @ 2014-10-16 13:51 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

On Oct 15, 2014, at 10:47 PM, Stefan Monnier wrote:

>The real underlying cause is dpkg's inability to handle simultaneous
>installs of different versions of the same package.  As a result, you
>get more work, as you point out, and I can't easily keep around all the
>versions I'd like to keep.

It depends.  We can install multiple different versions of Python
simultaneously, including both Python 2[*] and Python 3, but it took a lot of
work both in upstream and in Debian by the Python maintainers to make that
happen.

Cheers,
-Barry

[*] Although we only care about Python 2.7 now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-16 13:51       ` Barry Warsaw
@ 2014-10-16 17:19         ` Rob Browning
  2014-10-24  1:08           ` Rob Browning
  2014-10-16 20:01         ` Stefan Monnier
  1 sibling, 1 reply; 29+ messages in thread
From: Rob Browning @ 2014-10-16 17:19 UTC (permalink / raw)
  To: Barry Warsaw, emacs-devel

Barry Warsaw <barry@python.org> writes:

> It depends.  We can install multiple different versions of Python
> simultaneously, including both Python 2[*] and Python 3, but it took a lot of
> work both in upstream and in Debian by the Python maintainers to make that
> happen.

I suspect we handle emacsXY in a roughly similar way -- but I don't
think either one is /opt style; I suspect both follow the FHS.

The info pages complicate things a bit since we have to have
/usr/share/info/emacs-XY.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-16 13:51       ` Barry Warsaw
  2014-10-16 17:19         ` Rob Browning
@ 2014-10-16 20:01         ` Stefan Monnier
  2014-10-16 21:31           ` Barry Warsaw
                             ` (2 more replies)
  1 sibling, 3 replies; 29+ messages in thread
From: Stefan Monnier @ 2014-10-16 20:01 UTC (permalink / raw)
  To: Barry Warsaw; +Cc: emacs-devel

>> The real underlying cause is dpkg's inability to handle simultaneous
>> installs of different versions of the same package.  As a result, you
>> get more work, as you point out, and I can't easily keep around all the
>> versions I'd like to keep.
> It depends.  We can install multiple different versions of Python
> simultaneously, including both Python 2[*] and Python 3, but it took a lot of
> work both in upstream and in Debian by the Python maintainers to make that
> happen.

But you only get to do that by lying to dpkg and pretending that python2
and python3 are just different packages rather than different versions
of the package.  So you need to know beforehand which sets of packages
people may want to keep together.

The packaging of Emacs does the same with distinct emacs19, emacs20,
emacs21, emacs22, emacs23, and emacs24 packages, each with its own set
of versions.  For those users who only want "emacs", it leads to
superfluous packages lying around.  For the maintainers, it leads to
extra work.  And for users like me, it still doesn't let me cleanly
install Emacs-24.1, Emacs-24.2, and Emacs-24.3 at the same time.


        Stefan



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-16 20:01         ` Stefan Monnier
@ 2014-10-16 21:31           ` Barry Warsaw
  2014-10-17  1:04           ` Stephen J. Turnbull
  2014-10-18 21:20           ` Stephen Leake
  2 siblings, 0 replies; 29+ messages in thread
From: Barry Warsaw @ 2014-10-16 21:31 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

On Oct 16, 2014, at 04:01 PM, Stefan Monnier wrote:

>But you only get to do that by lying to dpkg and pretending that python2
>and python3 are just different packages rather than different versions
>of the package.  So you need to know beforehand which sets of packages
>people may want to keep together.

I'm not sure what you mean here, or whether Python's case is relevant to
Emacs, so I'll just mention the following and then re-lurk. :)

Each major Python version that Debian supports is a separate binary package,
e.g. python2.6, python2.7, python3.3, python3.4, etc. and that makes sense,
since each is an entirely different upstream release.  I don't see that as
"lying to dpkg"; for Python, it's true.

However, they are all co-installable, so you can have any combination of
whatever still-supported versions are in the archive.  The previous comment
about only caring about Python 2.7 is because all older versions are retired
upstream, and thus removed from Debian Jessie.

(Anything Python 3 older than 3.4 is currently in the same boat, but when
Python 3.5 is available, it's likely that both 3.4 and 3.5 will be supported
at the same time for a while.  No infrastructure changes will be needed to
enable that.)

Of course, "python" (i.e /usr/bin/python) and "python3" (/usr/bin/python3)
give you just one of those, whichever is the default version for Debian.
However, you can always also just run "python3.4" or "python3.5" or whatever.
I guess that's the analogy to "emacs" currently giving me 24.3.1 but being
able to run emacs23 if I wanted to... which I can. :)

The real trick to co-installability is that third party modules need to be
installable for all supported Pythons, and actually installed for all
installed Pythons.  Meaning, if package foo is available for 3.4, and then you
install Python 3.5, foo will magically also be available for 3.5 too.  Where
upstream got involved was redesigning the import system to support
co-installability of modules for multiple versions of Python (PEPs 3147 and
3149 for the interested Pythonista).  When Pythons earlier than 2.7 were still
around, Debian had to go jump through hoops (spelled "symlink farm") to make
that work, and it was a fragile hack.  Yet another reason to love Python 3. :)

It's also true that Debian has two different Python "stacks", one for Python 2
and another for Python 3.  That means if foo supports both, then you will have
a python-foo and a python3-foo binary package, but you will generally not have
a python3.4-foo and a python3.5-foo.  And in fact both binary packages are
usually created from the same upstream and Debian source package.  This makes
sense for Python because we do hope to some day remove Python 2, and in Ubuntu
demote Python 2 to universe.  There's also no need to install the Python 2
stack if you're just using Python 3.

Anyway, I'm off-topic for Emacs, so I'll stop here, except to add that Emacs
24.3 works really great for me on Debuntu.  Kudos to the maintainers.

/me waves to Rob.

Cheers,
-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-16 20:01         ` Stefan Monnier
  2014-10-16 21:31           ` Barry Warsaw
@ 2014-10-17  1:04           ` Stephen J. Turnbull
  2014-10-17  1:53             ` Stefan Monnier
  2014-10-18 21:20           ` Stephen Leake
  2 siblings, 1 reply; 29+ messages in thread
From: Stephen J. Turnbull @ 2014-10-17  1:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Barry Warsaw, emacs-devel

Stefan Monnier writes:

 > But you only get to do that by lying to dpkg and pretending that python2
 > and python3 are just different packages rather than different versions
 > of the package.

They are different packages, as different as, oh, Emacs and Guile. :)
It's possible to maintain sources that are compatible with both, but
their interpreters and standard libraries etc. are completely separate
now, and their dependencies are growing apart rapidly.

Your statement is true to a great extent among python2x packages, and
to some extent (more and more so over time) for python3x packages,
though.

 > And for users like me, it still doesn't let me cleanly install
 > Emacs-24.1, Emacs-24.2, and Emacs-24.3 at the same time.

I'm not clear on what you mean by "cleanly".  I suspect that in the
general case you need application bundles, with non-forward-compatible
dependencies installed in the bundle.  Of course when a version is
first released, you don't know when it will become non-forward-
compatible.

So I guess the solution would be to provide an option to statically
link any libraries that lack a strict backward compatibility promise.
But that has its problems too (although possibly not so much in your
application).

I suspect you are asking for the impossible.




^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-17  1:04           ` Stephen J. Turnbull
@ 2014-10-17  1:53             ` Stefan Monnier
  0 siblings, 0 replies; 29+ messages in thread
From: Stefan Monnier @ 2014-10-17  1:53 UTC (permalink / raw)
  To: Stephen J. Turnbull; +Cc: Barry Warsaw, emacs-devel

> I suspect you are asking for the impossible.

IIUC Nix/Guix has some kind of solution for this impossible problem.


        Stefan



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-16 20:01         ` Stefan Monnier
  2014-10-16 21:31           ` Barry Warsaw
  2014-10-17  1:04           ` Stephen J. Turnbull
@ 2014-10-18 21:20           ` Stephen Leake
  2014-10-18 22:03             ` Stefan Monnier
  2 siblings, 1 reply; 29+ messages in thread
From: Stephen Leake @ 2014-10-18 21:20 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The packaging of Emacs does the same with distinct emacs19, emacs20,
> emacs21, emacs22, emacs23, and emacs24 packages, each with its own set
> of versions.  For those users who only want "emacs", it leads to
> superfluous packages lying around.  For the maintainers, it leads to
> extra work.  And for users like me, it still doesn't let me cleanly
> install Emacs-24.1, Emacs-24.2, and Emacs-24.3 at the same time.

At the cost of a lot of disk space, you can install each of those in a
separate chroot. I don't know if that qualifies as "easily" for you; I
got used to chroot when I was maintaining a couple Debian packages.

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-18 21:20           ` Stephen Leake
@ 2014-10-18 22:03             ` Stefan Monnier
  2014-10-19  2:18               ` Stephen Leake
  0 siblings, 1 reply; 29+ messages in thread
From: Stefan Monnier @ 2014-10-18 22:03 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

> At the cost of a lot of disk space, you can install each of those in a
> separate chroot. I don't know if that qualifies as "easily" for you;

No, it definitely doesn't qualify.  First, because the problem is to
solve it within the Debian package system whereas your solution works
around it.  Second because if you're willing to solve it outside the
package system, then there are simpler solutions that use up a lot less
disk space ;-)

Among the solutions that use up less disk space:
- don't install the .debs but just compile manually and "make install".
- patch the .debs so they all get a different name.

> I got used to chroot when I was maintaining a couple Debian packages.

chroot can be handy, indeed, but it comes with its own set of problems.


        Stefan



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-18 22:03             ` Stefan Monnier
@ 2014-10-19  2:18               ` Stephen Leake
  2014-10-19  2:47                 ` Stefan Monnier
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Leake @ 2014-10-19  2:18 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> At the cost of a lot of disk space, you can install each of those in a
>> separate chroot. I don't know if that qualifies as "easily" for you;
>
> No, it definitely doesn't qualify.  First, because the problem is to
> solve it within the Debian package system whereas your solution works
> around it.  

Well, my point was you can use the Debian package system in each chroot,
and get different versions of the package installed.

I agree it would be nice to be able to do that in a single root, but I
suspect it is not possible in general, because there could be
conflicting requirements; you'd end up with full copies of /* for each
version anyway.

> - don't install the .debs but just compile manually and "make
> install".

This is certainly what I do, usually without the 'make install'.

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-19  2:18               ` Stephen Leake
@ 2014-10-19  2:47                 ` Stefan Monnier
  2014-10-19 17:53                   ` Stephen Leake
  0 siblings, 1 reply; 29+ messages in thread
From: Stefan Monnier @ 2014-10-19  2:47 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

> I agree it would be nice to be able to do that in a single root, but I
> suspect it is not possible in general, because there could be
> conflicting requirements; you'd end up with full copies of /* for each
> version anyway.

I can't see why.  I already have emacs19, emacs20, emacs21, emacs22,
emacs23, and emacs24 installed at the same time, so I can't see what new
problem would be introduced by refining this to the minor
version number.


        Stefan



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-19  2:47                 ` Stefan Monnier
@ 2014-10-19 17:53                   ` Stephen Leake
  2014-10-20  1:09                     ` Stefan Monnier
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Leake @ 2014-10-19 17:53 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I agree it would be nice to be able to do that in a single root, but I
>> suspect it is not possible in general, because there could be
>> conflicting requirements; you'd end up with full copies of /* for each
>> version anyway.
>
> I can't see why.  I already have emacs19, emacs20, emacs21, emacs22,
> emacs23, and emacs24 installed at the same time, so I can't see what new
> problem would be introduced by refining this to the minor
> version number.

For specific packages with similar dependencies, that works.

But suppose emacs19 depended on gtk1, and emacs20 on gtk2, emacs21 on
gtk3, etc. And each gtkn had different, changing dependencies as well.

You'd end up with unique copies of the entire dependency tree for each
emacsn.

In practice, since the dependencies are more stable than that, the total
tree would be much smaller than the full copy for each that you get from
the chroot approach.

I suspect, as has been said here before, the main problem is the
maintainer effort required to make installing minor versions in parallel
possible; renaming files to include version numbers in every file
name/path for each release. dpkg doesn't do that for you.

If you tried to upgrade dpkg to do the file/path versioning automatically,
it would have to take a very conservative approach, leading the full
copy as above.

That might work, but I suspect there would be problems; for example, if
C headers have "#include foo<version>;"; dpkg could not possibly be
expected to handle that by editing the file. Any hardcoded version in a
build script or source file would fail.

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-19 17:53                   ` Stephen Leake
@ 2014-10-20  1:09                     ` Stefan Monnier
  0 siblings, 0 replies; 29+ messages in thread
From: Stefan Monnier @ 2014-10-20  1:09 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

> I suspect, as has been said here before, the main problem is the
> maintainer effort required to make installing minor versions in parallel
> possible; renaming files to include version numbers in every file
> name/path for each release. dpkg doesn't do that for you.

For Emacs, this is a non-issue, since Emacs already includes the release
string in pretty much all the file names (with very chosen exceptions,
such as "bin/emacs").


        Stefan



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-16 17:19         ` Rob Browning
@ 2014-10-24  1:08           ` Rob Browning
  2014-10-24  6:57             ` Eli Zaretskii
  2014-10-24 15:31             ` Ulrich Mueller
  0 siblings, 2 replies; 29+ messages in thread
From: Rob Browning @ 2014-10-24  1:08 UTC (permalink / raw)
  To: Barry Warsaw, emacs-devel

Rob Browning <rlb@defaultvalue.org> writes:

> The info pages complicate things a bit since we have to have
> /usr/share/info/emacs-XY.

One other thing that would be handy (if it's not already possible) is an
easy way to generate and install info pages for multiple major releases
(at least) at the same time.

In Debian, as a hack, we just store all the pages under
.../share/info/emacs-N/, and then mangle the START-INFO-DIR-ENTRY to
refer to emacs-N/foo instead of foo. i.e.

  * Emacs: (emacs-24/emacs).               The extensible self-documenting text editor.

This works somewhat, but I seem to recall there were some issues with
either the standalone reader or Emacs (though perhaps they've been
fixed).

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-24  1:08           ` Rob Browning
@ 2014-10-24  6:57             ` Eli Zaretskii
  2014-10-24 15:31             ` Ulrich Mueller
  1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2014-10-24  6:57 UTC (permalink / raw)
  To: Rob Browning; +Cc: barry, emacs-devel

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Thu, 23 Oct 2014 20:08:15 -0500
> 
> One other thing that would be handy (if it's not already possible) is an
> easy way to generate and install info pages for multiple major releases
> (at least) at the same time.

That's not an Emacs problem.  This is a general problem with Texinfo:
it doesn't support such installation.  It's a long-standing missing
feature, so please take it up with the Texinfo developers, so that
perhaps in some not-so-distant future we might have a reliable
solution for it.

> In Debian, as a hack, we just store all the pages under
> .../share/info/emacs-N/, and then mangle the START-INFO-DIR-ENTRY to
> refer to emacs-N/foo instead of foo. i.e.
> 
>   * Emacs: (emacs-24/emacs).               The extensible self-documenting text editor.
> 
> This works somewhat, but I seem to recall there were some issues with
> either the standalone reader or Emacs (though perhaps they've been
> fixed).

Yes, this kludge is well known, but it doesn't work very well, as I'm
sure you know.

Again, this is a Texinfo problem.  Once Texinfo comes up with a
solution that the stand-alone Info reader implements, I'm sure Emacs
will follow suit in no time.



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Version naming
  2014-10-24  1:08           ` Rob Browning
  2014-10-24  6:57             ` Eli Zaretskii
@ 2014-10-24 15:31             ` Ulrich Mueller
  1 sibling, 0 replies; 29+ messages in thread
From: Ulrich Mueller @ 2014-10-24 15:31 UTC (permalink / raw)
  To: Rob Browning; +Cc: Barry Warsaw, emacs-devel

>>>>> On Thu, 23 Oct 2014, Rob Browning wrote:

>> The info pages complicate things a bit since we have to have
>> /usr/share/info/emacs-XY.

> One other thing that would be handy (if it's not already possible) is an
> easy way to generate and install info pages for multiple major releases
> (at least) at the same time.

> In Debian, as a hack, we just store all the pages under
> .../share/info/emacs-N/, and then mangle the START-INFO-DIR-ENTRY to
> refer to emacs-N/foo instead of foo. i.e.

>   * Emacs: (emacs-24/emacs).               The extensible self-documenting text editor.

> This works somewhat, but I seem to recall there were some issues with
> either the standalone reader or Emacs (though perhaps they've been
> fixed).

Similar workaround in Gentoo: We install the Info pages in
/usr/share/info/emacs-N/ (with e.g., N = 24) and add the directory
corresponding to the currently active Emacs version to the INFOPATH
environment variable. As an additional hack, we add the directory also
to Info-directory-list in Emacs' site initialisation (and make sure
that it occurs first in the list).

This way, each Emacs will see the right version of its Info pages.
The standalone reader will see the version that was added to INFOPATH.

Ulrich



^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2014-10-24 15:31 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-29 17:19 Version naming Stefan Monnier
2014-09-30  4:55 ` Drew Adams
2014-09-30  7:03 ` Thien-Thi Nguyen
2014-10-10  7:58   ` Thien-Thi Nguyen
2014-10-11  0:28     ` Glenn Morris
2014-10-11 11:18       ` Thien-Thi Nguyen
2014-10-15  7:13         ` Glenn Morris
2014-10-15 10:46           ` Thien-Thi Nguyen
2014-09-30 14:13 ` Lars Magne Ingebrigtsen
2014-09-30 14:17   ` Ted Zlatanov
2014-10-15 22:42   ` Rob Browning
2014-10-16  2:47     ` Stefan Monnier
2014-10-16  6:10       ` Stephen J. Turnbull
2014-10-16 13:51       ` Barry Warsaw
2014-10-16 17:19         ` Rob Browning
2014-10-24  1:08           ` Rob Browning
2014-10-24  6:57             ` Eli Zaretskii
2014-10-24 15:31             ` Ulrich Mueller
2014-10-16 20:01         ` Stefan Monnier
2014-10-16 21:31           ` Barry Warsaw
2014-10-17  1:04           ` Stephen J. Turnbull
2014-10-17  1:53             ` Stefan Monnier
2014-10-18 21:20           ` Stephen Leake
2014-10-18 22:03             ` Stefan Monnier
2014-10-19  2:18               ` Stephen Leake
2014-10-19  2:47                 ` Stefan Monnier
2014-10-19 17:53                   ` Stephen Leake
2014-10-20  1:09                     ` Stefan Monnier
2014-10-12 22:27 ` Jens K. Loewe

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).