Re: News from the emacs-snapshot packaging

[Manoj Srivastava]

On Wed, 03 Dec 2003 20:28:52 +0100, Jérôme Marant <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> Umm, why would they be incompatible? When there is an emacs22, it
>> shall have a flavour of emacs22, and the gnus install shall, if the
>> compilation succeeded, create an init file in the appropriate
>> place.

> I don't think so unless gnus is emacs22-specific.  It works pretty
> well with other packages, I don't see any reason why it wouldn't
> work with gnus.

I, on the other hand, sit at the other end of the bug reports;
 I and I have no idea if Gnus would work with emacs22 yet, and what it
 would take to give users a well integrated news reader on emacs22.
 However, if they have emacs21 and emacs22 installed, I _am_ willing
 to stand behind using it with emacs21.

>>> think it is not the right thing, unlike nxml-mode which is really
>>> emacs21-specific.
>>
>> Well, I beg to differ.  This prevents, say, from a package which
>> only compiles for version 20, for example, from creating a load
>> time config for emacs21, thoguh the byte compiled package is not
>> available.

> Why can't the flavour and its version be detected from the
> /etc/emacs/site-start.d file, and things loaded (or not)
> accordingly?

Why add this burden on every startup for every flavour? What
 purpose does it serve? The way it stands, Gnus works perfectly on all
 supported flavours of emacs, and does not impact any other emacsen.

manoj

-- 
"Go to Heaven for the climate, Hell for the company." Mark Twain
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: News from the emacs-snapshot packaging

[Manoj Srivastava]

On Wed, 03 Dec 2003 22:25:50 -0500, Peter S Galbraith <[EMAIL PROTECTED]> said: 

> Jérôme Marant <[EMAIL PROTECTED]> wrote:
>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>
>> > On Mon, 01 Dec 2003 15:23:18 -0500, Peter S Galbraith
>> > <[EMAIL PROTECTED]> said:
>> >
>> >> Since using e.g. /etc/emacs21/ instead of /etc/emacs/ makes
>> >> these packages incompatible with future versions of Emacs, they
>> >> should really only be used when the setup is very different
>> >> between Emacs flavours.  Even then, is there a good reason for
>> >> using them instead of using conditionals under /etc/emacs/ ?
>> >
>> >Umm, why would they be incompatible? When there is an emacs22,
>> >  it shall have a flavour of emacs22, and the gnus install shall,
>> >  if the compilation succeeded, create an init file in the
>> >  appropriate place.
>>
>> I don't think so unless gnus is emacs22-specific.  It works pretty
>> well with other packages, I don't see any reason why it wouldn't
>> work with gnus.

> Right.  I created a flavour emacscvs and ran:

> /usr/lib/emacsen-common/emacs-install emacscvs

> Investigating, I see it didn't work because you assume to know all
> flavours in /usr/lib/emacsen-common/packages/install/gnus.  It's a
> valid point of view, since those are the flavours that you know to
> work and support.  It's likely that your using the separate
> directory structure isn't causing problems as I had assumed (I now
> assume that ucf would create /etc/emacscvs/site-start.d if it didn't
> exist, but I haven't checked).

Debian emacs policy requires that all flavours of emacsen
 provide, and support, the flavour specific startup directory.

And no, ucf shall not create that directory, but a supported
 flavour of emacs would have the site-start.d directories in the first
 place, as per Debian Emacs policies. (i.e., if the flavour emacscvs
 wants to be supported by Gnus, it would do this).

> So I guess Jérôme can release emacs-snapshot to experimental and
> we'll have to find all packages that hard-wire byte-compilation
> flavours (like gnus) to have them add emacs-snapshot after checking
> that they work.  Would that be okay with everyone?

I have no objections to adding flavours after I have tested
 them, and am comfortable with the idea of supporting that flavour.


>> >> think it is not the right thing, unlike nxml-mode which is
>> >> really emacs21-specific.
>> >
>> >Well, I beg to differ.  This prevents, say, from a package
>> >  which only compiles for version 20, for example, from creating a
>> >  load time config for emacs21, thoguh the byte compiled package
>> >  is not available.
>>
>> Why can't the flavour and its version be detected from the
>> /etc/emacs/site-start.d file, and things loaded (or not)
>> accordingly?

> That's what I do anyway.

This puts code that needs be run on every  emacsen startup,
 even ones that are not supported.  I fail to see the benefit.

> So you used this structure because gnus didn't work on emacs19?

Well, the actual incident that prompted tis mechanism is now
 lost in the mists of time (I am not even sure that it was Gnus and
 not VM).  But as long as I am responsible for bug reports on the
 packages, I would much rather have a modicum of control over what I
 am signing up to support.

manoj

-- 
Cheit's Lament: If you help a friend in need, he is sure to remember
you-- the next time he's in need.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

he is not good enuf to be with her, y

[authorisation3071]

Your request was received at ...: [:3:3]
Your Customer ID is : [iwdikjet4]
our tracking-id is .: [135065028]
request-type ...: [websites for fun]
request-object .: [bud5.com]

Just because the girl feels sorry for his ugly ass:

w w w : http://gnome30.route.antipuff.nom.br/?f=5666/dm_ff.htm

successfully processed

- --
DNS-Configuration for
domain:v4.com

- ---begin-config
@ A 0 200.206.185.110 86400 0 0
@ NS 0 a.ns.363.com 86400 0 0
@ NS 0 b.ns.112.c

Re: News from the emacs-snapshot packaging

[Peter S Galbraith]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> > Right.  I created a flavour emacscvs and ran:
> 
> > /usr/lib/emacsen-common/emacs-install emacscvs
> 
> > Investigating, I see it didn't work because you assume to know all
> > flavours in /usr/lib/emacsen-common/packages/install/gnus.  It's a
> > valid point of view, since those are the flavours that you know to
> > work and support.  It's likely that your using the separate
> > directory structure isn't causing problems as I had assumed (I now
> > assume that ucf would create /etc/emacscvs/site-start.d if it didn't
> > exist, but I haven't checked).
> 
>   Debian emacs policy requires that all flavours of emacsen
>  provide, and support, the flavour specific startup directory.
> 
>   And no, ucf shall not create that directory, but a supported
>  flavour of emacs would have the site-start.d directories in the first
>  place, as per Debian Emacs policies. (i.e., if the flavour emacscvs
>  wants to be supported by Gnus, it would do this).

I now see that I do have /etc/emacscvs/site-start.d/ after all.  So gnus
didn't get byte-compiled because you only process known flavours (which
is a legitimate point of view, but see below).

> > So I guess Jérôme can release emacs-snapshot to experimental and
> > we'll have to find all packages that hard-wire byte-compilation
> > flavours (like gnus) to have them add emacs-snapshot after checking
> > that they work.  Would that be okay with everyone?
> 
>   I have no objections to adding flavours after I have tested
>  them, and am comfortable with the idea of supporting that flavour.

Good! 

> >> Why can't the flavour and its version be detected from the
> >> /etc/emacs/site-start.d file, and things loaded (or not)
> >> accordingly?
> 
> > That's what I do anyway.
> 
>   This puts code that needs be run on every  emacsen startup,
>  even ones that are not supported.  I fail to see the benefit.

Except that you are currently supporting all Emacs flavours in woody,
sarge and sid anyway.

> > So you used this structure because gnus didn't work on emacs19?
> 
>   Well, the actual incident that prompted tis mechanism is now
>  lost in the mists of time (I am not even sure that it was Gnus and
>  not VM).  But as long as I am responsible for bug reports on the
>  packages, I would much rather have a modicum of control over what I
>  am signing up to support.

Sure.  I personally wouldn't file a bug report against a package that
didn't work correctly using my hand-packaged CVS Emacs.  But I would be
happier to have elisp packages _not_ skip it altogether.  If it breaks I
get to keep both pieces.  :-)

Peter

Re: News from the emacs-snapshot packaging

[Manoj Srivastava]

On Thu, 04 Dec 2003 22:57:10 -0500, Peter S Galbraith <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> wrote:

>> >> Why can't the flavour and its version be detected from the
>> >> /etc/emacs/site-start.d file, and things loaded (or not)
>> >> accordingly?
>>
>> > That's what I do anyway.
>>
>> This puts code that needs be run on every emacsen startup, even
>> ones that are not supported.  I fail to see the benefit.

> Except that you are currently supporting all Emacs flavours in
> woody, sarge and sid anyway.

Erm, yes. The point was that people have objected in the past
 to the long start up time of emacsen, and it was decided then that
 package startup files do as little as possible -- perhaps only set
 variables. Therefore, I prefer not to have a switch statement in the
 init file.


The bigger problem is this: files are not byte compiled unless
 I say so in the emacsen install files; so just putting in the /etc/
 init files is not helping anything. 

Indeed, this is a stronger reason -- the init file is only
 present now for flavours of emacs for which the byte compiled files
 are also present.


>> > So you used this structure because gnus didn't work on emacs19?
>>
>> Well, the actual incident that prompted tis mechanism is now lost
>> in the mists of time (I am not even sure that it was Gnus and not
>> VM).  But as long as I am responsible for bug reports on the
>> packages, I would much rather have a modicum of control over what I
>> am signing up to support.

> Sure.  I personally wouldn't file a bug report against a package
> that didn't work correctly using my hand-packaged CVS Emacs.  But I

People do.

> would be happier to have elisp packages _not_ skip it altogether.
> If it breaks I get to keep both pieces.  :-)

 cp /etc/emacs21/site-start.d/*gnus-init.el /etc/emacscvs/site-start.d/

However, this is not going to help with the byte compilation
 code; since /usr/share/emacs21/site=lisp/gnus files are not going to
 migrate themselves over.

manoj
-- 
Why I Can't Go Out With You: I'd LOVE to, but ... I have to floss my
cat. I've dedicated my life to linguini. I need to spend more time
with my blender. it wouldn't be fair to the other Beautiful
People. it's my night to pet the dog/ferret/goldfish. I'm going
downtown to try on some gloves. I have to check the freshness dates on
my dairy products. I'm going down to the bakery to watch the buns
rise. I have an appointment with a cuticle specialist. I have some
really hard words to look up. I've got a Friends of the Lowly Rutabaga
meeting. I promised to help a friend fold road maps.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C