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-22-2008, 07:24 PM
Steve Langasek
 
Default RFC: Idea for improved diversions and alternatives handling

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 errors and can easily leave
> diversions or alternatives behind. Instead I suggest creating two new
> control files detailing the diversions and alternatives a package
> should have.

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, and that's just nasty.
I'm happy to see people thinking about this.

However,

> New control file: diversions
> ============================

> A package wanting to divert files can list them in the control.tar.gz
> in a file named "diversions" using the following syntax:

> Empty lines and lines starting with # are comments. All other lines
> contain:

> [dpkg-divert option] ... file

> Dpkg will automatically add --package <package> and -add or --remove
> before file. If --rename is used without --divert <divert-to> then
> --divert <file>.<package> is added as well.

> On install dpkg will add all listed diversions before unpacking.
> On removal dpkg will remove all listed diversions after deletion.
> On updates/downgrades dpkg will add new diversions before unpacking
> and remove no longer listed diversions after deletion.

> 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 already been
rumblings from him about implementing declarative diversions.

> New control file: alternatives
> ==============================

The need for declarative alternatives is much less clear because
alternatives can always be managed during a normal postinst/prerm stage,
and there are definitely cases when update-alternatives from a maintainer
script is still the only correct way to handle some alternatives. These
two proposals should be handled separately.

--
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-22-2008, 10:49 PM
Goswin von Brederlow
 
Default RFC: Idea for improved diversions and alternatives handling

Steve Langasek <vorlon@debian.org> 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 already been
> rumblings from him about implementing declarative diversions.

The problem is that changes in --rename will be insane.

For example package A 1.0 has diverted /usr/bin/foo from package B
with --rename and ships /usr/bin/foo itself.

Now imagine package A 2.0 drops the --rename option.

A 1.0 postrm expects /usr/bin/foo to be from A 1.0. On the other hand
A 2.0 expects /usr/bin/foo to come from B in preinst while the actual
file is from A 1.0. So you have to move /usr/bin/foo to
/usr/bin/foo.dpkg-$RANDOM (to be able to abort-install), rename
/usr/bin/foo.B back to /usr/bin/foo and then run preinst. And in
case of errors you have to revert it all back.


Would anyone have a problem if dpkgs diversion handling would always
use --rename? Because if we eliminate that from being an option the
changes become easy.

Also a diversion without --rename can not be cleanly removed by
dpkg. The original file would be gone for all dpkg knows. Another
reason to always use --rename by dpkg.

MfG
Goswin


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

Steve Langasek <vorlon@debian.org> 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 already been
> rumblings from him about implementing declarative diversions.

The problem is that changes in --rename will be insane.

For example package A 1.0 has diverted /usr/bin/foo from package B
with --rename and ships /usr/bin/foo itself.

Now imagine package A 2.0 drops the --rename option.

A 1.0 postrm expects /usr/bin/foo to be from A 1.0. On the other hand
A 2.0 expects /usr/bin/foo to come from B in preinst while the actual
file is from A 1.0. So you have to move /usr/bin/foo to
/usr/bin/foo.dpkg-$RANDOM (to be able to abort-install), rename
/usr/bin/foo.B back to /usr/bin/foo and then run preinst. And in
case of errors you have to revert it all back.


Would anyone have a problem if dpkgs diversion handling would always
use --rename? Because if we eliminate that from being an option the
changes become easy.

Also a diversion without --rename can not be cleanly removed by
dpkg. The original file would be gone for all dpkg knows. Another
reason to always use --rename by dpkg.

MfG
Goswin


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

On Mon, Jun 23, 2008 at 12:49:08AM +0200, Goswin von Brederlow wrote:
> Steve Langasek <vorlon@debian.org> 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 already been
> > rumblings from him about implementing declarative diversions.

> The problem is that changes in --rename will be insane.

> For example package A 1.0 has diverted /usr/bin/foo from package B
> with --rename and ships /usr/bin/foo itself.

> Now imagine package A 2.0 drops the --rename option.

> A 1.0 postrm expects /usr/bin/foo to be from A 1.0. On the other hand
> A 2.0 expects /usr/bin/foo to come from B in preinst while the actual
> file is from A 1.0. So you have to move /usr/bin/foo to
> /usr/bin/foo.dpkg-$RANDOM (to be able to abort-install), rename
> /usr/bin/foo.B back to /usr/bin/foo and then run preinst. And in
> case of errors you have to revert it all back.

> Would anyone have a problem if dpkgs diversion handling would always
> use --rename? Because if we eliminate that from being an option the
> changes become easy.

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?

I don't think that the meaning of dpkg-divert (without --rename) should be
changed, but I think that for declarative diversions, it makes sense to only
support "rename".

--
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-23-2008, 07:43 AM
Steve Langasek
 
Default RFC: Idea for improved diversions and alternatives handling

On Mon, Jun 23, 2008 at 12:49:08AM +0200, Goswin von Brederlow wrote:
> Steve Langasek <vorlon@debian.org> 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 already been
> > rumblings from him about implementing declarative diversions.

> The problem is that changes in --rename will be insane.

> For example package A 1.0 has diverted /usr/bin/foo from package B
> with --rename and ships /usr/bin/foo itself.

> Now imagine package A 2.0 drops the --rename option.

> A 1.0 postrm expects /usr/bin/foo to be from A 1.0. On the other hand
> A 2.0 expects /usr/bin/foo to come from B in preinst while the actual
> file is from A 1.0. So you have to move /usr/bin/foo to
> /usr/bin/foo.dpkg-$RANDOM (to be able to abort-install), rename
> /usr/bin/foo.B back to /usr/bin/foo and then run preinst. And in
> case of errors you have to revert it all back.

> Would anyone have a problem if dpkgs diversion handling would always
> use --rename? Because if we eliminate that from being an option the
> changes become easy.

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?

I don't think that the meaning of dpkg-divert (without --rename) should be
changed, but I think that for declarative diversions, it makes sense to only
support "rename".

--
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-23-2008, 09:31 AM
Goswin von Brederlow
 
Default RFC: Idea for improved diversions and alternatives handling

Steve Langasek <vorlon@debian.org> 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 /lib/libc-2.7.so
cp /lib/libc-2.7.so /lib/libc-2.7.so.my-libc6-wrapper

and

mv /lib/libc-2.7.so.my-libc6-wrapper /lib/libc-2.7.so
dpkg-divert --package my-libc6-wrapper --remove /lib/libc-2.7.so

A case where an intervall without the file is unacceptable.

> I don't think that the meaning of dpkg-divert (without --rename) should be
> changed, but I think that for declarative diversions, it makes sense to only
> support "rename".

MfG
Goswin


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

Steve Langasek <vorlon@debian.org> 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 /lib/libc-2.7.so
cp /lib/libc-2.7.so /lib/libc-2.7.so.my-libc6-wrapper

and

mv /lib/libc-2.7.so.my-libc6-wrapper /lib/libc-2.7.so
dpkg-divert --package my-libc6-wrapper --remove /lib/libc-2.7.so

A case where an intervall without the file is unacceptable.

> I don't think that the meaning of dpkg-divert (without --rename) should be
> changed, but I think that for declarative diversions, it makes sense to only
> support "rename".

MfG
Goswin


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

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, and that's just nasty.
> I'm happy to see people thinking about this.

Absolutely. I would agree with Steve Langasek's comments, though.

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 ?
--rename
Should always be enabled in this case. The situations where
this isn't right don't apply, and for declarative diversions
we're expecting dpkg to Do The Right Thing all of the time.
--admindir --test --quiet --help --version --truename --list
Make no sense in a diversions file

Which leaves only the pathname :-).

> 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.

> You should perhaps discuss this with Ian Jackson, there have already been
> rumblings from him about implementing declarative diversions.

After my last experience I don't have any plans to do any substantial
coding in dpkg :-/.

> > New control file: alternatives
> > ==============================
>
> The need for declarative alternatives is much less clear because
> alternatives can always be managed during a normal postinst/prerm stage,
> and there are definitely cases when update-alternatives from a maintainer
> script is still the only correct way to handle some alternatives. These
> two proposals should be handled separately.

Absolutely. I would suggest at least doing the design work
sequentially. Otherwise we'll all get more confused.

Steve Langasek writes ("Re: RFC: Idea for improved diversions and alternatives handling"):
> 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?

Goswin's answer is one example - although actually the odds of a
package maintainer doing the diversion of an essential file correctly
are quite low. --rename should have been the default (sorry).

Ian.


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

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, and that's just nasty.
> I'm happy to see people thinking about this.

Absolutely. I would agree with Steve Langasek's comments, though.

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 ?
--rename
Should always be enabled in this case. The situations where
this isn't right don't apply, and for declarative diversions
we're expecting dpkg to Do The Right Thing all of the time.
--admindir --test --quiet --help --version --truename --list
Make no sense in a diversions file

Which leaves only the pathname :-).

> 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.

> You should perhaps discuss this with Ian Jackson, there have already been
> rumblings from him about implementing declarative diversions.

After my last experience I don't have any plans to do any substantial
coding in dpkg :-/.

> > New control file: alternatives
> > ==============================
>
> The need for declarative alternatives is much less clear because
> alternatives can always be managed during a normal postinst/prerm stage,
> and there are definitely cases when update-alternatives from a maintainer
> script is still the only correct way to handle some alternatives. These
> two proposals should be handled separately.

Absolutely. I would suggest at least doing the design work
sequentially. Otherwise we'll all get more confused.

Steve Langasek writes ("Re: RFC: Idea for improved diversions and alternatives handling"):
> 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?

Goswin's answer is one example - although actually the odds of a
package maintainer doing the diversion of an essential file correctly
are quite low. --rename should have been the default (sorry).

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:40 AM
Tollef Fog Heen
 
Default RFC: Idea for improved diversions and alternatives handling

* 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 with a bit of
thought and great care, it is sometimes necessary. In that case, making
sure the diverted library goes to a separate directory often makes sense
to avoid confusing ldconfig. Therefore, I would like to be able to
specify the path to be diverted to, not just the pathname to be
diverted. I guess we could make it optional, so the common case would
just be:

debian/foo.divert:
/bin/ls

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).

--
Tollef Fog Heen / Linpro AS t: 21 54 41 73

UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 02:55 PM.

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