FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 06-27-2008, 06:52 PM
Ian Jackson
 
Default RFC: Idea for improved diversions and alternatives handling

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, but it probably makes sense
> for it to be dpkg, making sure it's root:root 0644).

If we can get the ordering right perhaps we can delay the actual
renaming of the file to the new name until the replacement from the
diverting packages' version is unpacked. Then diverting package's
filesystem archive could contain the directory and it wouldn't
necessarily be too late.

Ian.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-27-2008, 06:52 PM
Ian Jackson
 
Default RFC: Idea for improved diversions and alternatives handling

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, but it probably makes sense
> for it to be dpkg, making sure it's root:root 0644).

If we can get the ordering right perhaps we can delay the actual
renaming of the file to the new name until the replacement from the
diverting packages' version is unpacked. Then diverting package's
filesystem archive could contain the directory and it wouldn't
necessarily be too late.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-27-2008, 06:56 PM
Ian Jackson
 
Default RFC: Idea for improved diversions and alternatives handling

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. And the only
> other option I see (other than diversions) is to prohibit changing
> /bin/sh, which will make a lot of people very upset.
>
> I agree that alternatives are the optimal tool here, but I don't know
> how that can be achieved. Suggestions welcome.

So you're saying this situation calls for diverting a file to make way
for an alternative. This seems like it will involve the diversions
and alternatives mechanisms fighting each other. It'll have a great
many moving parts and probably be buggy.

This scenario leads me to suggest that perhaps the right answer is to
unify diversions and alternatives. If we can come up with a single
mostly-dpkg-implemented feature to do both then we at least have some
chance to get it right. (It might also help with some of the
transition problems I mentioned earlier.)

I haven't thought this through yet but I'll sleep on it and see if it
becomes any clearer ...

Ian.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-27-2008, 06:56 PM
Ian Jackson
 
Default RFC: Idea for improved diversions and alternatives handling

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. And the only
> other option I see (other than diversions) is to prohibit changing
> /bin/sh, which will make a lot of people very upset.
>
> I agree that alternatives are the optimal tool here, but I don't know
> how that can be achieved. Suggestions welcome.

So you're saying this situation calls for diverting a file to make way
for an alternative. This seems like it will involve the diversions
and alternatives mechanisms fighting each other. It'll have a great
many moving parts and probably be buggy.

This scenario leads me to suggest that perhaps the right answer is to
unify diversions and alternatives. If we can come up with a single
mostly-dpkg-implemented feature to do both then we at least have some
chance to get it right. (It might also help with some of the
transition problems I mentioned earlier.)

I haven't thought this through yet but I'll sleep on it and see if it
becomes any clearer ...

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-27-2008, 07:38 PM
James Vega
 
Default RFC: Idea for improved diversions and alternatives handling

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 ? What about original files, what do they become ?
> >
> > Several packages shouldn't divert the same file, IMO. diversions
> > are useful for specific circumstances and the diverted/diverting
> > packages should be closely related (if not from the source).
> > Alternatives are the better solution when there are myriad,
> > non-conflicting sources which may provide the same file.
>
> That's all very well but what about transitions ?

This would fall under closely related packages. My point was mainly
that diversions need to be thought out and coordinated before being
used as they have more restrictions than alternatives (such as not
supporting multiple packages providing a file that another package
declared a diversion for).

> This all needs some careful thought I think, to make sure we get all
> of the corner cases right.

Agreed. Getting this implemented correctly will be very useful to
those situations where diversions are the right solution.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 
Old 06-27-2008, 07:38 PM
James Vega
 
Default RFC: Idea for improved diversions and alternatives handling

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 ? What about original files, what do they become ?
> >
> > Several packages shouldn't divert the same file, IMO. diversions
> > are useful for specific circumstances and the diverted/diverting
> > packages should be closely related (if not from the source).
> > Alternatives are the better solution when there are myriad,
> > non-conflicting sources which may provide the same file.
>
> That's all very well but what about transitions ?

This would fall under closely related packages. My point was mainly
that diversions need to be thought out and coordinated before being
used as they have more restrictions than alternatives (such as not
supporting multiple packages providing a file that another package
declared a diversion for).

> This all needs some careful thought I think, to make sure we get all
> of the corner cases right.

Agreed. Getting this implemented correctly will be very useful to
those situations where diversions are the right solution.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 
Old 06-27-2008, 07:53 PM
"brian m. carlson"
 
Default RFC: Idea for improved diversions and alternatives handling

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
can't wait for the alternatives mechanism to be set up. And the only
other option I see (other than diversions) is to prohibit changing
/bin/sh, which will make a lot of people very upset.

I agree that alternatives are the optimal tool here, but I don't know
how that can be achieved. Suggestions welcome.


So you're saying this situation calls for diverting a file to make way
for an alternative. This seems like it will involve the diversions
and alternatives mechanisms fighting each other. It'll have a great
many moving parts and probably be buggy.


No. I said that I'd prefer /bin/sh to be managed by alternatives. I
also said that /bin/sh is essential, even at the very beginning of
installation. I also demonstrated a case where diversions may have to
be used, even though they're (IMHO) a poor choice, unless some brilliant
person figures out how to make alternatives work.

I did not suggest diverting a file to make way for an alternative. I
agree that down that path, madness lies.


This scenario leads me to suggest that perhaps the right answer is to
unify diversions and alternatives. If we can come up with a single
mostly-dpkg-implemented feature to do both then we at least have some
chance to get it right. (It might also help with some of the
transition problems I mentioned earlier.)


I'm certainly interested in hearing more.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 06-28-2008, 09:03 AM
Steve Langasek
 
Default RFC: Idea for improved diversions and alternatives handling

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 diversions file would be better.

> Looking at the options to dpkg-divert:

> --add --remove --package
> Should be inferred by dpkg and not specifiable in diversions
> --divert
> In practice diversity in this option seems to cause more
> trouble than it's worse. Perhaps we should settle on
> `.diverted' or something ?

<snip>

> > On Sun, Jun 22, 2008 at 07:05:29PM +0200, Goswin von Brederlow wrote:
> > > 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.

> Quite so. Changes to the diversions must be handled properly.
> Also we need to think about the semantics when a diversion is
> specified by more than one package, which might be necessary during
> package transitions.

Right. Nested diversions probably aren't a very clever idea, despite being
possible today; but how else do we handle a diversion moving from one
package to another? I guess we could require that packages which provide
the same diverted file must conflict with one another, but that seems
inelegant to me compared to the status quo if the packages don't otherwise
conflict.

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" by default, since we wouldn't want diversions from multiple
packages to collide. Maybe ".diverted-$package", then?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-28-2008, 09:03 AM
Steve Langasek
 
Default RFC: Idea for improved diversions and alternatives handling

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 diversions file would be better.

> Looking at the options to dpkg-divert:

> --add --remove --package
> Should be inferred by dpkg and not specifiable in diversions
> --divert
> In practice diversity in this option seems to cause more
> trouble than it's worse. Perhaps we should settle on
> `.diverted' or something ?

<snip>

> > On Sun, Jun 22, 2008 at 07:05:29PM +0200, Goswin von Brederlow wrote:
> > > 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.

> Quite so. Changes to the diversions must be handled properly.
> Also we need to think about the semantics when a diversion is
> specified by more than one package, which might be necessary during
> package transitions.

Right. Nested diversions probably aren't a very clever idea, despite being
possible today; but how else do we handle a diversion moving from one
package to another? I guess we could require that packages which provide
the same diverted file must conflict with one another, but that seems
inelegant to me compared to the status quo if the packages don't otherwise
conflict.

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" by default, since we wouldn't want diversions from multiple
packages to collide. Maybe ".diverted-$package", then?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-28-2008, 10:37 PM
James Vega
 
Default RFC: Idea for improved diversions and alternatives handling

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" by default, since we wouldn't want diversions from multiple
> packages to collide. Maybe ".diverted-$package", then?

I don't think this scenario makes sense outside of transitioning a
diversion from one package to another.

There are two use cases to consider regarding multiple packages and
diversions.

1) Multiple packages installing a file that has been diverted.
Currently, there is only one "divert to" filename so you'll end up
losing data once the second diverted file is installed. This could be
alleviated by instead basing the "divert to" filename on the package
which contains the file being diverted (as you suggest above).

There's still the problem of what to do when the package providing the
diversion is uninstalled as now you have conflicting packages.
Actually, you already had conflicting packages that just weren't
affected yet because of the diversion, which leads to 2).

2) Multiple packages diverting the same file.
This currently isn't possible since dpkg-divert will rightly complain
about multiple packages trying to divert the same file. If it were to
be possible, you would need a layered approach with priorities so
there's a defined notion of which package is currently providing the
contested file and who would do so when that package is removed. In
this case, congratulations, you've reinvented alternatives.

So it seems like the solution to both of the above scenarios is the use
of alternatives. There is the problem which brian brought up[0] about
using diversions when you can't rely on having alternatives setup
already but that would be obviated if dpkg internally handled both
diversions and alternatives.

[0] - 20080627172930.GB7523@crustytoothpaste.ath.cx
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 

Thread Tools




All times are GMT. The time now is 09:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org