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
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
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
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
> ".diver
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 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 immedi
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 severa
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 alternative
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
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 f
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
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 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
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 somet
* 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 wi
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 orde
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 --
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
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, the
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
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
21 matches
Mail list logo
