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
