Malcolm Parsons <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 30, 2002 at 08:41:38PM -0500, Peter S Galbraith wrote:
> > A lot of maintainers don't mark the files there as confiles because they
> > don't expect them to be edited.
>
> If you don't expect them to be edited then having them as conffile
Ben Pfaff <[EMAIL PROTECTED]> writes:
> Has anyone taken a look at "InfoDock: The Incredible IDE"? From
> the description, it sounds interesting, but I haven't yet gone to
> the trouble of looking any closer:
They've been around for a long time (I used to use hyperbole several
years ago) but suf
Has anyone taken a look at "InfoDock: The Incredible IDE"? From
the description, it sounds interesting, but I haven't yet gone to
the trouble of looking any closer:
http://sourceforge.net/projects/infodock/
InfoDock is an integrated productivity toolset, mainly
aimed at t
> Hello.
>
> I have re-read the logs for this bug from the beginning, and I see
> that I have been wrongly assuming (sorry!) that a Depends: emacsen-common in
> gettext would force the user to install some emacs flavour, but in fact
> emacsen-common just says:
>
> Depends: bsdmainutils
>
> Just
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> >>"Peter" == Peter S Galbraith <[EMAIL PROTECTED]> writes:
>
> Peter> Is this needed at all? (See the other thread).
>
> Yes.
>
> Peter> If all the current flavors of Emacs automatically add the
> Peter> subdirectories in the load-path, we
> From: Rob Browning <[EMAIL PROTECTED]>
> Date: Thu, 31 Jan 2002 12:27:29 -0600
>
> Though we've tried to figure out ways we could handle this locally, it
> seems like without upstream support, we're not likely to have a very
> clean solution. So has any thought been given to this issue, and is
[ In summary of what's below, I'm asking asking if there's upstream
interest in trying to get info pages to handle the installation of
multiple versions of a given program gracefully. ]
I hope I have the right list, and I hope this hasn't already been
discussed to death. If either is false,
Rob Browning wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
> > [ emacsen-common is a relatively small package. Making gettext to
> > depend on it, even if you don't plan to use emacs po-mode at all,
> > would not be such a tragedy ].
>
> If you're OK with that, I'm OK with that -- it'll probab
Santiago Vila <[EMAIL PROTECTED]> writes:
> Just in case I'm missing anything: Am I right that it's completely
> possible to install emacsen-common and not installing any emacs
> flavour?
Right. Things need to depend on emacsen-common to make sure that the
required infrastructure is in place, bu
Hello.
I have re-read the logs for this bug from the beginning, and I see
that I have been wrongly assuming (sorry!) that a Depends: emacsen-common in
gettext would force the user to install some emacs flavour, but in fact
emacsen-common just says:
Depends: bsdmainutils
Just in case I'm missing
Well, I'd thought this list had been very quiet for a long time, but I
guess it was in fact "too quiet". Today I was surprised that some of
the messages that I was sending to the list weren't ending up in my
debian-emacsen mail group.
Checking my suspicions, I found out that I wasn't in fact sub
> * gettext does not need a Depends, it just needs a better
> emacs-package-install implementation, namely, one that does not fail
> if emacsen-common has not been configured yet.
If we can figure out a way that we're *sure* will work right, then I'm
OK with changing emacsen-common so that add-on
Toby Speight <[EMAIL PROTECTED]> writes:
> What happens if emacsen is installed *after* package 'foo' that uses
> it? AIUI, foo won't get its emacs components configured at all then.
Actually now that I've thought about this yet further, I don't think
this is a problem.
If emacsen-common is bei
On Wed, 30 Jan 2002, Peter S Galbraith wrote:
> > Toby Speight <[EMAIL PROTECTED]> writes:
> >
> > > Rob> If this were in fact "safe", then we could think about changing
> > > Rob> debian-emacs-policy to fully eliminate the requirement that packages
> > > Rob> that have emacs components *depend* o
14 matches
Mail list logo
