Neil Williams [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
working on dpkg reminded me that I wanted to propose a better
diversion and alternatives handling for debian packages. Currently
they have to be manually added and removed in the maintainer
scripts. This method is prone to
Goswin von Brederlow wrote:
working on dpkg reminded me that I wanted to propose a better
diversion and alternatives handling for debian packages. Currently
they have to be manually added and removed in the maintainer
scripts. This method is prone to errors and can easily leave
diversions or
James Vega [EMAIL PROTECTED] writes:
On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote:
So if we allow multiple packages to be installed at the same time which
divert the same file, then I think we have another case for wanting to
continue supporting an optional diversion target
On Thu, Jun 26, 2008 at 10:05:53PM +0100, Ian Jackson wrote:
I don't think replicating the options to dpkg-divert in the diversions
file is the correct approach. The implementation won't be done by
having dpkg call dpkg-divert (I hope!) and I think a less arbitrary
set of syntaxes for the
On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote:
So if we allow multiple packages to be installed at the same time which
divert the same file, then I think we have another case for wanting to
continue supporting an optional diversion target - or at least for not using
.diverted
* Ian Jackson
| --divert
| In practice diversity in this option seems to cause more
| trouble than it's worse. Perhaps we should settle on
| `.diverted' or something ?
[...]
| Which leaves only the pathname :-).
While diverting libraries is something that should be done
On Fri, Jun 27, 2008 at 08:40:35AM +0200, Tollef Fog Heen wrote:
* Ian Jackson
| --divert
| In practice diversity in this option seems to cause more
| trouble than it's worse. Perhaps we should settle on
| `.diverted' or something ?
I like this idea. Going for something
On Thu, Jun 26, 2008 at 10:05:53PM +0100, Ian Jackson wrote:
Steve Langasek writes (Re: RFC: Idea for improved diversions and
alternatives handling):
Declarative diversions are a much-needed enhancement to dpkg; there are
cases one cannot deal with on upgrade without rm'ing one's own
On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
What should happen when several packages divert the same file ?
Which one wins ? What about original files, what do they become ?
Several packages shouldn't divert the same file, IMO. diversions
are useful for specific circumstances
On Fri, Jun 27, 2008 at 12:58:14PM -0400, James Vega wrote:
On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
What should happen when several packages divert the same file ?
Which one wins ? What about original files, what do they become ?
Several packages shouldn't divert the same
James Vega writes (Re: RFC: Idea for improved diversions and alternatives
handling):
On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
What should happen when several packages divert the same file ?
Which one wins ? What about original files, what do they become ?
Several
Tollef Fog Heen writes (Re: RFC: Idea for improved diversions and alternatives
handling):
And the uncommon case:
debian/foo.divert:
/lib/libc.so.6 /lib/foo/libc.so.6
(Whose responsibility it is to ensure /lib/foo exists in that scenario
is something I'm not completely sure about
brian m. carlson writes (Re: RFC: Idea for improved diversions and
alternatives handling):
You still have to handle multiple diversions for /bin/sh. When d-i
installs the system, you have to have a working /bin/sh immediately; you
can't wait for the alternatives mechanism to be set up
On Fri, Jun 27, 2008 at 07:34:53PM +0100, Ian Jackson wrote:
James Vega writes (Re: RFC: Idea for improved diversions and alternatives
handling):
On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
What should happen when several packages divert the same file ?
Which one wins
On Fri, Jun 27, 2008 at 07:56:41PM +0100, Ian Jackson wrote:
brian m. carlson writes (Re: RFC: Idea for improved diversions and alternatives
handling):
You still have to handle multiple diversions for /bin/sh. When d-i
installs the system, you have to have a working /bin/sh immediately; you
Steve Langasek writes (Re: RFC: Idea for improved diversions and alternatives
handling):
Declarative diversions are a much-needed enhancement to dpkg; there are
cases one cannot deal with on upgrade without rm'ing one's own package files
in the prerm in order to handle diversion changes
On Mon, Jun 23, 2008 at 12:49:08AM +0200, Goswin von Brederlow wrote:
Steve Langasek [EMAIL PROTECTED] writes:
FIXME: what if a line changes? Only allow certain changes?
... that's a rather large FIXME. Without fixing this, such an
implementation of declarative diversions would be
Steve Langasek [EMAIL PROTECTED] writes:
Er, I've for the life of me never understood why --rename is even an
*option* to dpkg-divert. What does dpkg-divert do without it, and how is
that useful?
Only thing I can think of is something like this:
dpkg-divert --package my-libc6-wrapper --add
Hi,
working on dpkg reminded me that I wanted to propose a better
diversion and alternatives handling for debian packages. Currently
they have to be manually added and removed in the maintainer
scripts. This method is prone to errors and can easily leave
diversions or alternatives behind. Instead
On Sun, Jun 22, 2008 at 07:05:29PM +0200, Goswin von Brederlow wrote:
working on dpkg reminded me that I wanted to propose a better
diversion and alternatives handling for debian packages. Currently
they have to be manually added and removed in the maintainer
scripts. This method is prone to
Steve Langasek [EMAIL PROTECTED] writes:
FIXME: what if a line changes? Only allow certain changes?
... that's a rather large FIXME. Without fixing this, such an
implementation of declarative diversions would be pointless churn.
You should perhaps discuss this with Ian Jackson, there have
21 matches
Mail list logo
