Moving diversions between packages

[Russ Allbery]

. Do something else to move the diversions that I haven't thought of and
   that would wonderfully solve all of our problems.

I'd love to get opinions on what we should do here.  It seems like moving
diversions between packages is something that we would have run into in
the past and should have a good answer for.

In the absence of (4), I'm currently leaning towards option (1), but I
don't know if I'm missing something that makes that even less robust than
I think it is.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aapjwrux@windlord.stanford.edu

Re: Moving diversions between packages

[Ian Jackson]

Russ Allbery writes ("Moving diversions between packages"):
> 4. Do something else to move the diversions that I haven't thought of and
>that would wonderfully solve all of our problems.

Why not have the new package ship libGL.so.1 to a more specific
filename and create a symlink named libGL.so.1 by hand in its 
postinst ?  That way you can defer doing the diversion until that part
of the postinst, by which time the old package and its diversion are
gone.

IWBNI dpkg handled diversions much more internally than it does, but
it's a complicated problem.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19528.22286.516091.339...@chiark.greenend.org.uk

Re: Moving diversions between packages

[Steve Langasek]

Hi Russ,

On Thu, Jul 22, 2010 at 06:47:34AM -0700, Russ Allbery wrote:

> We're attempting to solve this problem by splitting out just the libGL
> library into a separate package (libgl1-nvidia) that can be independently
> installed.  However, that means the diversions of libGL have to move from
> nvidia-glx to this new package.  And that's where we ran into problems.

Somewhat orthogonal to your original question, but the Ubuntu nvidia
packages have recently switched to using alternatives instead of diversions
for managing the libgl bits for various reasons.  It would be great if
Debian and Ubuntu could get synced up on this... and maybe moving to
alternatives solves the problem with moving diversions, since alternatives
don't have the unpack ordering problem that diversions do.  Cc:ing the
Ubuntu nvidia package maintainer to make him aware of this discussion.

-- 
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [pkg-nvidia-devel] Moving diversions between packages

[Russ Allbery]

Ian Jackson  writes:

> Why not have the new package ship libGL.so.1 to a more specific filename
> and create a symlink named libGL.so.1 by hand in its postinst ?  That
> way you can defer doing the diversion until that part of the postinst,
> by which time the old package and its diversion are gone.

Oh, huh, I hadn't thought of that.  But wouldn't this cause the library to
temporarily disappear, which would be contrary to the last paragraph of
Policy 8.1?  Am I being too conservative about that?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871vat24ju@windlord.stanford.edu

Re: [pkg-nvidia-devel] Moving diversions between packages

[Goswin von Brederlow]

Russ Allbery  writes:

> Ian Jackson  writes:
>
>> Why not have the new package ship libGL.so.1 to a more specific filename
>> and create a symlink named libGL.so.1 by hand in its postinst ?  That
>> way you can defer doing the diversion until that part of the postinst,
>> by which time the old package and its diversion are gone.
>
> Oh, huh, I hadn't thought of that.  But wouldn't this cause the library to
> temporarily disappear, which would be contrary to the last paragraph of
> Policy 8.1?  Am I being too conservative about that?

For the split second between the dpkg-divert and the ln call on install
or between the rm and dpkg-divert on removal. I think you are too
conservative there.

You are refering to "between the time that dpkg installs it and the time
that ldconfig is run in the postinst script", right? But the disapearing
would be only for a split second while your postinst runs.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxthp8t2@frosties.localdomain

Re: [pkg-nvidia-devel] Moving diversions between packages

[Ian Jackson]

Goswin von Brederlow writes ("Re: [pkg-nvidia-devel] Moving diversions between 
packages"):
> Russ Allbery  writes:
> > Ian Jackson  writes:
> > > Why not have the new package ship libGL.so.1 to a more specific filename
> > > and create a symlink named libGL.so.1 by hand in its postinst ?  That
> > > way you can defer doing the diversion until that part of the postinst,
> > > by which time the old package and its diversion are gone.
> >
> > Oh, huh, I hadn't thought of that.  But wouldn't this cause the library to
> > temporarily disappear, which would be contrary to the last paragraph of
> > Policy 8.1?  Am I being too conservative about that?

Maybe.  The point of policy 8.1 is so that the package can be upgraded
without rendering all of the things which depend on it unable to
start.  If you do as I suggest you'll undo the diversion and link in
the prerm, and thus every time the package is upgraded it will revert
back to the previous version and (presumably) all the things which are
linked against it will stop working.

Does that matter ?

> For the split second between the dpkg-divert and the ln call on install
> or between the rm and dpkg-divert on removal. I think you are too
> conservative there.

No, I don't think that's quite right, for the reasons I give above.

> You are refering to "between the time that dpkg installs it and the time
> that ldconfig is run in the postinst script", right? But the disapearing
> would be only for a split second while your postinst runs.

It would be better not to have it broken even for a split second -
after all, something might go wrong and interrupt the process at that
point.  But I think in my suggestion it will be broken for much
longer.

Perhaps it would be possible to somehow design an arrangement where
the first time you install the new library package it waits until the
postinst to do its diversion, but otherwise it leaves it be and
doesn't mess with the links.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19532.5062.998350.945...@chiark.greenend.org.uk

Re: [pkg-nvidia-devel] Moving diversions between packages

[Goswin von Brederlow]

Ian Jackson  writes:

> Goswin von Brederlow writes ("Re: [pkg-nvidia-devel] Moving diversions 
> between packages"):
>> Russ Allbery  writes:
>> > Ian Jackson  writes:
>> > > Why not have the new package ship libGL.so.1 to a more specific filename
>> > > and create a symlink named libGL.so.1 by hand in its postinst ?  That
>> > > way you can defer doing the diversion until that part of the postinst,
>> > > by which time the old package and its diversion are gone.
>> >
>> > Oh, huh, I hadn't thought of that.  But wouldn't this cause the library to
>> > temporarily disappear, which would be contrary to the last paragraph of
>> > Policy 8.1?  Am I being too conservative about that?
>
> Maybe.  The point of policy 8.1 is so that the package can be upgraded
> without rendering all of the things which depend on it unable to
> start.  If you do as I suggest you'll undo the diversion and link in
> the prerm, and thus every time the package is upgraded it will revert
> back to the previous version and (presumably) all the things which are
> linked against it will stop working.
>
> Does that matter ?

Why should one undo the diversion and link for an upgrade? That only
needs to happen on removal.

>> For the split second between the dpkg-divert and the ln call on install
>> or between the rm and dpkg-divert on removal. I think you are too
>> conservative there.
>
> No, I don't think that's quite right, for the reasons I give above.
>
>> You are refering to "between the time that dpkg installs it and the time
>> that ldconfig is run in the postinst script", right? But the disapearing
>> would be only for a split second while your postinst runs.
>
> It would be better not to have it broken even for a split second -
> after all, something might go wrong and interrupt the process at that
> point.  But I think in my suggestion it will be broken for much
> longer.

Divert without renaming and then overwrite the file with ln -fs. That
should do it atomically or not?

But you are right, if your suggestion is to undo this in prerm then
there will be a long delay between undoing and redoing. But if you fully
undo things then programs will still start, they just won't be able to
use hardware accelerated GL and fallback to software GL.

> Perhaps it would be possible to somehow design an arrangement where
> the first time you install the new library package it waits until the
> postinst to do its diversion, but otherwise it leaves it be and
> doesn't mess with the links.
>
> Ian.

In prerm you do nothing for "upgrade", remove the diversion+link for
"remove" and restore it for "failed-upgrade".

And in postinst you create the diversion+link for "configure" if it does
not exist already.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkxfeahh@frosties.localdomain

Re: [pkg-nvidia-devel] Moving diversions between packages

[Russ Allbery]

Ian Jackson  writes:
> Goswin von Brederlow writes:
>> Russ Allbery  writes:

>>> Oh, huh, I hadn't thought of that.  But wouldn't this cause the
>>> library to temporarily disappear, which would be contrary to the last
>>> paragraph of Policy 8.1?  Am I being too conservative about that?

> Maybe.  The point of policy 8.1 is so that the package can be upgraded
> without rendering all of the things which depend on it unable to start.
> If you do as I suggest you'll undo the diversion and link in the prerm,
> and thus every time the package is upgraded it will revert back to the
> previous version and (presumably) all the things which are linked
> against it will stop working.

I was planning on not removing the link and diversion until the postrm,
actually, just as if it had been managed with the preinst file.  The
package Conflicts with the older version of nvidia-glx, so there shouldn't
be a need for it to be unconfigured but not removed with the old
nvidia-glx installed.  So basically it's the same window between two
commands in both the postinst and the postrm.

The idea would be to, after the squeeze release, switch back to managing
the diversion in the preinst file in the traditional way.

> Perhaps it would be possible to somehow design an arrangement where the
> first time you install the new library package it waits until the
> postinst to do its diversion, but otherwise it leaves it be and doesn't
> mess with the links.

I think that's what the above accomplishes, although the code to remove
the diversion will need to cope with the possibility that it was never
created since the postinst never ran (since postrm can be run for packages
whose postinst was never executed).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871varla42@windlord.stanford.edu

Re: [pkg-nvidia-devel] Moving diversions between packages

[Russ Allbery]

Goswin von Brederlow  writes:

> But you are right, if your suggestion is to undo this in prerm then
> there will be a long delay between undoing and redoing. But if you fully
> undo things then programs will still start, they just won't be able to
> use hardware accelerated GL and fallback to software GL.

No, that's not correct.  libGL.so.1 would disappear, which means that any
programs linked with that shared library would not be able to start at
all.

> In prerm you do nothing for "upgrade", remove the diversion+link for
> "remove" and restore it for "failed-upgrade".

I'm not seeing why the diversion and link should be manipulated in prerm
at all rather than in postrm the way that they would be if they were
managed in preinst.  But I could very well be missing something.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrsjjvgk@windlord.stanford.edu

Re: [pkg-nvidia-devel] Moving diversions between packages

[Goswin von Brederlow]

Russ Allbery  writes:

> Goswin von Brederlow  writes:
>
>> But you are right, if your suggestion is to undo this in prerm then
>> there will be a long delay between undoing and redoing. But if you fully
>> undo things then programs will still start, they just won't be able to
>> use hardware accelerated GL and fallback to software GL.
>
> No, that's not correct.  libGL.so.1 would disappear, which means that any
> programs linked with that shared library would not be able to start at
> all.

*fully* undo. That means you delete the link, undo the diversion and
move the original libGL.so.1 back into place. So it would be there. But
as said there is no need to undo the diversion for an upgrade.

>> In prerm you do nothing for "upgrade", remove the diversion+link for
>> "remove" and restore it for "failed-upgrade".
>
> I'm not seeing why the diversion and link should be manipulated in prerm
> at all rather than in postrm the way that they would be if they were
> managed in preinst.  But I could very well be missing something.

- nvidias prerm runs
- nvidias libGL.so.1 is removed by dpkg
- libGL.so.1 is now a dangling symlink
- dpkg still runs and does some bookkeeping and syncing
- nvidias postrm runs

If you remove the diversion in postrm then there is a window where the
link is dangling. The same window existing packages with diversions in
preinst/postrm do have. Removing the diversion in prerm avoids that
window but that only works with your link.

If you remove the diversion in postrm there probably won't be any
complaints but you could do it perfect in prerm.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w4zuugr@frosties.localdomain

Re: [pkg-nvidia-devel] Moving diversions between packages

[Russ Allbery]

Goswin von Brederlow  writes:
> Russ Allbery  writes:
>> Goswin von Brederlow  writes:

>>> But you are right, if your suggestion is to undo this in prerm then
>>> there will be a long delay between undoing and redoing. But if you
>>> fully undo things then programs will still start, they just won't be
>>> able to use hardware accelerated GL and fallback to software GL.

>> No, that's not correct.  libGL.so.1 would disappear, which means that
>> any programs linked with that shared library would not be able to start
>> at all.

> *fully* undo. That means you delete the link, undo the diversion and
> move the original libGL.so.1 back into place. So it would be there. But
> as said there is no need to undo the diversion for an upgrade.

Oh, I see what you're saying.  Right.  And if the user is removing the
NVIDIA libGL libraries, having hardware-accelerated GL for NVIDIA cards go
away is probably their intended action.

> - nvidias prerm runs
> - nvidias libGL.so.1 is removed by dpkg
> - libGL.so.1 is now a dangling symlink
> - dpkg still runs and does some bookkeeping and syncing
> - nvidias postrm runs

> If you remove the diversion in postrm then there is a window where the
> link is dangling. The same window existing packages with diversions in
> preinst/postrm do have. Removing the diversion in prerm avoids that
> window but that only works with your link.

> If you remove the diversion in postrm there probably won't be any
> complaints but you could do it perfect in prerm.

Ah, yes, good point.

The NVIDIA package already installs its libGL under a different name than
libGL.so.1.2 and handles the libGL.so symlink separately (via a trigger),
so the only file affected by this is libGL.so.1.  I like this idea of
moving the handling of it to postinst, and I think all the other
diversions for the libgl1-nvidia package can also be moved to postinst.

Andreas, do you see anything about this that I'm missing that would cause
problems?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sk35vq9c@windlord.stanford.edu