Timo Juhani Lindfors writes:
> What sort of helpers do you think should be offered?
[...]
> Having almost all packages use shared code would improve the quality a
> lot. Currently many packages fail in some tiny details (for example
> they forget to symlink .el files => emacs help can not find
Rob Browning writes:
>prerm:
> rm -f /var/lib/ec/state/package/installed/PACKAGE
> for flavor in /var/lib/ec/state/flavor/installed/*
>/usr/lib/emacsen-common/packages/install/PACKAGE $flavor
Obviously that should be remove/PACKAGE.
--
Rob Browning
rlb @defaultvalue.org a
Rob Browning writes:
>> so that we could get rid of all the copypasted shell script snippets
>> that do byte compilation in unique and interesting ways?
>
> This might be a good idea, though I'd probably want to arrange it so
> that packages can still handle things themselves if they need to.
sur
Timo Juhani Lindfors writes:
> Thanks for working on this. Can you comment on
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619480#79
>
> ? Particularly, could
>
> /usr/lib/emacsen-common/packages/install/PACKAGE
>
> in the future just include a call to something like
>
> emacsen-install-
Hi Rob,
Rob Browning writes:
>postinst:
> for flavor in /var/lib/ec/state/flavor/installed/*
>/usr/lib/emacsen-common/packages/install/PACKAGE $flavor
> touch /var/lib/ec/state/package/installed/PACKAGE
Thanks for working on this. Can you comment on
http://bugs.debian.org
Rob Browning writes:
> So I think I'm going to adjust the tree I've been hacking on to
> implement this and see how it looks. Does anyone have any objections or
> complaints?
>
> Here's what I'm planning (more or less):
>
> - Have a canonical state file (or state files) for every add-on,
>
Agustin Martin wrote:
> On Mon, Jul 26, 2010 at 12:38:54PM -0400, Peter S Galbraith wrote:
> > Rob Browning wrote:
> >
> > > - Require all updated add-on packages and emacs flavors to declare a
> > > "Conflicts: emacsen-common (<< UPDATED-EMACSEN-VERSION)".
> >
> > One of the nice things
On Mon, Jul 26, 2010 at 12:38:54PM -0400, Peter S Galbraith wrote:
> Rob Browning wrote:
>
> > - Require all updated add-on packages and emacs flavors to declare a
> > "Conflicts: emacsen-common (<< UPDATED-EMACSEN-VERSION)".
>
> One of the nice things about Emacs add-on packages is that t
Rob Browning wrote:
> - Require all updated add-on packages and emacs flavors to declare a
> "Conflicts: emacsen-common (<< UPDATED-EMACSEN-VERSION)".
One of the nice things about Emacs add-on packages is that the latest
unstable could usually be installed on stable. We'd lose this abilit
On Sun, Jul 18, 2010 at 05:37:23PM -0500, Rob Browning wrote:
> Rob Browning writes:
> I think this may allow us to remove the requirement that add-on packages
> depend on emacs flavors, and may fix the bugs we've been discussing. It
> may also make it possible to avoid some duplicate add-on pack
On Thu, Jul 08, 2010 at 10:22:23PM -0500, Rob Browning wrote:
> Agustin Martin writes:
> > For the records, dictionaries-common uses flags like
> >
> > /usr/share/$flavour/site-lisp/dictionaries-common/done
> >
> > to signal that things are already built and do not need further rebuild.
> > It is
Rob Browning writes:
> - Require all add-on packages to specify --postinst when calling
> emacs-package-install from their postinst. That will make it
> possible to detect updated add-on packages.
>
> - Require emacs flavors to call emacs-install with comparable
> --postinst and
Rob Browning writes:
> I'd be quite happy if we really can eliminate any need for add-on
> packages to depend on emacsen-common. The main objection I have to the
> use of installed-flavors is that it's an implementation detail (and one
> I've been thinking about changing), but I'm fine with addi
Agustin Martin writes:
> I think we should put that check into add-ons, not emacsen-common, so
> it does not need rewrite. For the records that has been done in
> dictionaries-common for years using the 'installed-flavours' trick
> (Yes, I will change to something better as soon as needed) and no
On Wed, Jul 07, 2010 at 12:57:19PM +0200, Agustin Martin wrote:
> > > lisp stuff in a package whose main use is not Emacs should be used if
> > > an emacsen package is installed and ignored otherwise. There is nothing
> > > wrong
> > > with that. Even if /var/lib/emacsen-common/installed-flavors w
Ian Jackson wrote:
> Rob Browning writes ("Re: RFC: relaxation of debian-emacs-policy dependency
> requirements"):
> > If the package doesn't need to use any of the emacsen-common build
> > infrastructure (doesn't need to byte-compile for each flavor, etc.)
On Tue, Jul 06, 2010 at 10:46:57PM -0500, Rob Browning wrote:
> Ian Jackson writes:
>
> > Rob Browning writes ("RFC: relaxation of debian-emacs-policy dependency
> > requirements"):
> >> After some investigation, it looks like we might be able to chan
On Tue, Jul 06, 2010 at 10:54:33PM -0500, Rob Browning wrote:
> Agustin Martin writes:
>
> > On Tue, Jul 06, 2010 at 11:51:06AM +0100, Ian Jackson wrote:
>
> >> Why should a package which happens to also ship some elisp need to
> >> depend on any Emacs package at all ? What will go wrong if the
Rob Browning writes ("Re: RFC: relaxation of debian-emacs-policy dependency
requirements"):
> If the package doesn't need to use any of the emacsen-common build
> infrastructure (doesn't need to byte-compile for each flavor, etc.),
> then it doesn't need to hav
Agustin Martin writes:
> On Tue, Jul 06, 2010 at 11:51:06AM +0100, Ian Jackson wrote:
>> Why should a package which happens to also ship some elisp need to
>> depend on any Emacs package at all ? What will go wrong if the
>> package is installed without any Emacs ?
>
> Agreed.
>
> lisp stuff in
Ian Jackson writes:
> Rob Browning writes ("RFC: relaxation of debian-emacs-policy dependency
> requirements"):
>> After some investigation, it looks like we might be able to change
>> policy to just require add-on packages to depend on emacsen-common,
>> whi
On Tue, Jul 06, 2010 at 11:51:06AM +0100, Ian Jackson wrote:
> Rob Browning writes ("RFC: relaxation of debian-emacs-policy dependency
> requirements"):
> > After some investigation, it looks like we might be able to change
> > policy to just require add-on packages
Rob Browning writes ("RFC: relaxation of debian-emacs-policy dependency
requirements"):
> After some investigation, it looks like we might be able to change
> policy to just require add-on packages to depend on emacsen-common,
> which is reasonably small, ~150k, and could prob
[Mail-Followup-To set to debian-emacsen.]
I've been looking in to some of the issues surrounding current policy,
and one common, long-standing complaint has been about the requirement
that add-on packages depend either on emacsen, or on some combination of
emacs flavors.
That requirement is what
24 matches
Mail list logo