Mailing List Archive

Well, you should know that those are because of portage bugs or some
portage peculiarity, read the corresponding bugs for example for cups
to find out more.

Regards,
Stefan

--
gentoo-dev@gentoo.org mailing list

On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> Well, you should know that those are because of portage bugs or some
> portage peculiarity, read the corresponding bugs for example for cups
> to find out more.

Can you point me to a bug? There's no mention in the ChangeLog that I can see
nor in the ebuilds themselves...

--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list

On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > Well, you should know that those are because of portage bugs or some
> > portage peculiarity, read the corresponding bugs for example for cups
> > to find out more.
>
> Can you point me to a bug? There's no mention in the ChangeLog that I can see
> nor in the ebuilds themselves...

Bug #99375 is mentioned in the changelog for samba.

On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > Well, you should know that those are because of portage bugs or some
> > > portage peculiarity, read the corresponding bugs for example for cups
> > > to find out more.
> >
> > Can you point me to a bug? There's no mention in the ChangeLog that I can
> > see nor in the ebuilds themselves...
>
> Bug #99375 is mentioned in the changelog for samba.

It still doesn't explain why it's necessary.

--
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > Well, you should know that those are because of portage bugs or some
> > > portage peculiarity, read the corresponding bugs for example for cups
> > > to find out more.
> >
> > Can you point me to a bug? There's no mention in the ChangeLog that I can
> > see nor in the ebuilds themselves...
>
> Bug #99375 is mentioned in the changelog for samba.

Okay. It appears to be something related to symlinks. Can you show me the bug
assigned to portage that reports this and/or shows how to reproduce it?

--
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

On Fri, Dec 23, 2005 at 10:00:20PM +0900, Jason Stubbs wrote:
> On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > > Well, you should know that those are because of portage bugs or some
> > > > portage peculiarity, read the corresponding bugs for example for cups
> > > > to find out more.
> > >
> > > Can you point me to a bug? There's no mention in the ChangeLog that I can
> > > see nor in the ebuilds themselves...
> >
> > Bug #99375 is mentioned in the changelog for samba.
>
> Okay. It appears to be something related to symlinks. Can you show me the bug
> assigned to portage that reports this and/or shows how to reproduce it?

Don't know if it's been reported as a portage bug, but this would show
it:

KEYWORDS="~x86"
src_install() {
dodir /test
dosym /usr/bin /test
}

When unmerging, portage won't remove /test/bin because its target still exists.

Harald van Dijk wrote:
>
> Don't know if it's been reported as a portage bug, but this would show
> it:
>
> KEYWORDS="~x86"
> src_install() {
> dodir /test
> dosym /usr/bin /test
> }
>
> When unmerging, portage won't remove /test/bin because its target still exists.

That is fixed in portage-2.0.53 (latest stable).

http://bugs.gentoo.org/show_bug.cgi?id=59593

Zac
--
gentoo-dev@gentoo.org mailing list

On Friday 23 December 2005 22:13, Harald van Dijk wrote:
> On Fri, Dec 23, 2005 at 10:00:20PM +0900, Jason Stubbs wrote:
> > On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> > > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > > > Well, you should know that those are because of portage bugs or
> > > > > some portage peculiarity, read the corresponding bugs for example
> > > > > for cups to find out more.
> > > >
> > > > Can you point me to a bug? There's no mention in the ChangeLog that I
> > > > can see nor in the ebuilds themselves...
> > >
> > > Bug #99375 is mentioned in the changelog for samba.
> >
> > Okay. It appears to be something related to symlinks. Can you show me the
> > bug assigned to portage that reports this and/or shows how to reproduce
> > it?
>
> Don't know if it's been reported as a portage bug, but this would show
> it:
>
> KEYWORDS="~x86"
> src_install() {
> dodir /test
> dosym /usr/bin /test
> }
>
> When unmerging, portage won't remove /test/bin because its target still
> exists.

Seeing that there's no bug filed for this, discussion can go here; that's no
existance of a portage bug is of itself no reason to put an ugly workaround
in the ebuilds themselves mind you.

Symlinks are handled within portage differently to regular files. Regular
files get an mtime check and are removed if it matches. Symlinks don't get an
mtime check (even thought the mtime is stored) and are only removed if the
symlink's target doesn't exist. Hence, it seems to be this way by design. Why
it's this way? Who knows. It's been that way for longer than anyone can
remember which is why _it's so important that bugs get filed_.

A quick patch makes symlinks handled similarly to regular files and solves the
issue. I'll put it into testing unless anybody can come up with a reason not
to. The case that will be broken by the patch is when two different packages
install the same symlink.　PackageA is installed, PackageB is installed,
PackageB is uninstalled -> PackageA is broken. Does this case exist?

--
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

On Saturday 24 December 2005 02:11, Zac Medico wrote:
> Harald van Dijk wrote:
> > Don't know if it's been reported as a portage bug, but this would show
> > it:
> >
> > KEYWORDS="~x86"
> > src_install() {
> > dodir /test
> > dosym /usr/bin /test
> > }
> >
> > When unmerging, portage won't remove /test/bin because its target still
> > exists.
>
> That is fixed in portage-2.0.53 (latest stable).
>
> http://bugs.gentoo.org/show_bug.cgi?id=59593

Similar characteristics but slightly different.

--
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote:
> Symlinks are handled within portage differently to regular files. Regular
> files get an mtime check and are removed if it matches. Symlinks don't get an
> mtime check (even thought the mtime is stored) and are only removed if the
> symlink's target doesn't exist. Hence, it seems to be this way by design. Why
> it's this way? Who knows. It's been that way for longer than anyone can
> remember which is why _it's so important that bugs get filed_.

Honestly, I thought it was supposed to be like that, since
collision-protect also doesn't protect against packages overwriting
each other's symlinks (package A and package B can both create
/dummy -> bin without any problems from portage). Do you want a bug
report for that?

On Saturday 24 December 2005 02:52, Harald van Dijk wrote:
> On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote:
> > Symlinks are handled within portage differently to regular files. Regular
> > files get an mtime check and are removed if it matches. Symlinks don't
> > get an mtime check (even thought the mtime is stored) and are only
> > removed if the symlink's target doesn't exist. Hence, it seems to be this
> > way by design. Why it's this way? Who knows. It's been that way for
> > longer than anyone can remember which is why _it's so important that bugs
> > get filed_.
>
> Honestly, I thought it was supposed to be like that, since
> collision-protect also doesn't protect against packages overwriting
> each other's symlinks (package A and package B can both create
> /dummy -> bin without any problems from portage).

As far as portage source goes, it is meant to be like that. But as far as
portage source goes, installed package information isn't necessary for dep
calculation (including depclean)... Most code has been reviewed and the major
issues are known by at least one person, but there is still some code that
hasn't suffered a close examination (yet alone reworking) such as the code
that the above bug hits.

> Do you want a bug report for that?

Yes, please.

--
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

On Sat, 24 Dec 2005 02:22:06 +0900
Jason Stubbs <jstubbs@gentoo.org> wrote:

> PackageA is installed, PackageB is installed, PackageB is
> uninstalled -> PackageA is broken. Does this case exist?

Found two on my system:

* "/usr/lib/X11/app-defaults -> /etc/X11/app-defaults" is
installed by several X11 apps (media-gfx/xfig, x11-misc/seyon,
x11-misc/xvkbd, and i would not be surprised there are others)

* "/usr/share/cups/model/foomatic-ppds -> /usr/share/ppd" is
installed by both net-print/foomatic-db and net-print/hplip.

Maybe this particular packages could be hacked to avoid need for
the symlinks (or the symlinks should be installed only by some
lower level, depended-on, packages?), but anyway it would be hard
to do a strict sanity check of the whole tree. And letting that to
"collision-protect" feature doesn't sound really like a short term
solution neither. So, basically, i don't see how you could safely
change this portage behavior atm (although i agree it would be a
good thing once done).

--
TGL.
--
gentoo-dev@gentoo.org mailing list

On Sat, Dec 24, 2005 at 03:09:47AM +0900, Jason Stubbs wrote:
> On Saturday 24 December 2005 02:52, Harald van Dijk wrote:
> > On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote:
> > > Symlinks are handled within portage differently to regular files. Regular
> > > files get an mtime check and are removed if it matches. Symlinks don't
> > > get an mtime check (even thought the mtime is stored) and are only
> > > removed if the symlink's target doesn't exist. Hence, it seems to be this
> > > way by design. Why it's this way? Who knows. It's been that way for
> > > longer than anyone can remember which is why _it's so important that bugs
> > > get filed_.
> >
> > Honestly, I thought it was supposed to be like that, since
> > collision-protect also doesn't protect against packages overwriting
> > each other's symlinks (package A and package B can both create
> > /dummy -> bin without any problems from portage).
>
> As far as portage source goes, it is meant to be like that. But as far as
> portage source goes, installed package information isn't necessary for dep
> calculation (including depclean)... Most code has been reviewed and the major
> issues are known by at least one person, but there is still some code that
> hasn't suffered a close examination (yet alone reworking) such as the code
> that the above bug hits.
>
> > Do you want a bug report for that?
>
> Yes, please.

Okay, reported as bug #116511.

Duncan wrote:
> It just sounds like it /could/ be dangerous to me. For some reason, I
> don't like the idea of something that could hose a system that badly! =8^\

It won't hose your system badly, since you've got /usr/lib64 listed in
/etc/ld.so.conf. I agree it wouldn't be very nice though.

--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
--
gentoo-dev@gentoo.org mailing list

On Saturday 24 December 2005 03:43, Duncan wrote:
> Jason Stubbs posted <200512240222.06574.jstubbs@gentoo.org>, excerpted
>
> below, on Sat, 24 Dec 2005 02:22:06 +0900:
> > A quick patch makes symlinks handled similarly to regular files and
> > solves the issue. I'll put it into testing unless anybody can come up
> > with a reason not to. The case that will be broken by the patch is when
> > two different packages install the same symlink. PackageA is
> > installed, PackageB is installed, PackageB is uninstalled -> PackageA is
> > broken. Does this case exist?
>
> Yikes! That's not going to remove /lib or /usr/lib or the like, for us on
> amd64, where that's a symlink to lib64, will it?
>
> equery b /lib
> [ Searching for file(s) /lib in *... ]
> net-analyzer/macchanger-1.5.0-r1 (/lib)
> sys-apps/baselayout-1.12.0_pre12 (/lib)
> sys-boot/grub-0.97 (/lib)
> sys-devel/gcc-4.0.2-r1 (/lib)
> sys-devel/gcc-3.4.4-r1 (/lib)
> sys-fs/device-mapper-1.01.05 (/lib)
> sys-fs/lvm2-2.01.14 (/lib)
> sys-fs/udev-078 (/lib)
> sys-libs/glibc-2.3.6 (/lib)
>
> There's a similar, longer list, for /usr/lib. Obviously, not all of
> those will own it as a symlink, but it is one, and if removing one happens
> to remove the symlink...

I'm not familiar with equery so I don't know what this output means. By the
look of it, it is only a list of packages that own stuff in that directory.

> Also consider the effect where a former dir is now a symlink or a former
> symlink is now a dir. The recent xorg directory moves come to mind.

With the patch I've done, recorded symlinks will continue to be ignored if the
target is not a symlink.

> You are /sure/ the new code won't screw anything of that sort up, right?
> Maybe that's the reason nobody seems to have been around to know about.
> It just sounds like it /could/ be dangerous to me. For some reason, I
> don't like the idea of something that could hose a system that badly! =8^\

*Please* don't tell me you run ~arch.

--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list

On Saturday 24 December 2005 03:42, Thomas de Grenier de Latour wrote:
> On Sat, 24 Dec 2005 02:22:06 +0900
>
> Jason Stubbs <jstubbs@gentoo.org> wrote:
> > PackageA is installed, PackageB is installed, PackageB is
> > uninstalled -> PackageA is broken. Does this case exist?
>
> Found two on my system:
>
> * "/usr/lib/X11/app-defaults -> /etc/X11/app-defaults" is
> installed by several X11 apps (media-gfx/xfig, x11-misc/seyon,
> x11-misc/xvkbd, and i would not be surprised there are others)

This looks like something that a lower level X ebuild should be installing.
The problem here is that there's also a bit of funny business going on when
portage encounters a merge of some filetype being blocked by a different
filetype. In the above case, if some X11 package installs
the /usr/lib/X11/app-defaults symlink and all other apps install
to /etc/X11/app-defaults then everything should be fine.

> * "/usr/share/cups/model/foomatic-ppds -> /usr/share/ppd" is
> installed by both net-print/foomatic-db and net-print/hplip.

Again, given the name of the symlink, net-print/hplip should probably be
installing directly to /usr/share/ppd.

> Maybe this particular packages could be hacked to avoid need for
> the symlinks (or the symlinks should be installed only by some
> lower level, depended-on, packages?), but anyway it would be hard
> to do a strict sanity check of the whole tree. And letting that to
> "collision-protect" feature doesn't sound really like a short term
> solution neither. So, basically, i don't see how you could safely
> change this portage behavior atm (although i agree it would be a
> good thing once done).

Yep, it seems that changing the behaviour will lead to some breakage. However
repoman is definately not capable of handling this sort of stuff. Also, none
of the breakage (that you've revealed here at least) is that bad. Putting the
relevant collision-protect changes into ~arch and following up with the
actual unmerge changes should lead to minimal disruption on the user's side.

--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list

Jason Stubbs posted <200512240222.06574.jstubbs@gentoo.org>, excerpted
below, on Sat, 24 Dec 2005 02:22:06 +0900:

> A quick patch makes symlinks handled similarly to regular files and
> solves the issue. I'll put it into testing unless anybody can come up
> with a reason not to. The case that will be broken by the patch is when
> two different packages install the same symlink. PackageA is
> installed, PackageB is installed, PackageB is uninstalled -> PackageA is
> broken. Does this case exist?

Yikes! That's not going to remove /lib or /usr/lib or the like, for us on
amd64, where that's a symlink to lib64, will it?

equery b /lib
[ Searching for file(s) /lib in *... ]
net-analyzer/macchanger-1.5.0-r1 (/lib)
sys-apps/baselayout-1.12.0_pre12 (/lib)
sys-boot/grub-0.97 (/lib)
sys-devel/gcc-4.0.2-r1 (/lib)
sys-devel/gcc-3.4.4-r1 (/lib)
sys-fs/device-mapper-1.01.05 (/lib)
sys-fs/lvm2-2.01.14 (/lib)
sys-fs/udev-078 (/lib)
sys-libs/glibc-2.3.6 (/lib)

There's a similar, longer list, for /usr/lib. Obviously, not all of
those will own it as a symlink, but it is one, and if removing one happens
to remove the symlink...

Also consider the effect where a former dir is now a symlink or a former
symlink is now a dir. The recent xorg directory moves come to mind.

You are /sure/ the new code won't screw anything of that sort up, right?
Maybe that's the reason nobody seems to have been around to know about.
It just sounds like it /could/ be dangerous to me. For some reason, I
don't like the idea of something that could hose a system that badly! =8^\

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Jason Stubbs posted <200512240406.05350.jstubbs@gentoo.org>, excerpted
below, on Sat, 24 Dec 2005 04:06:05 +0900:

>> You are /sure/ the new code won't screw anything of that sort up, right?
>> Maybe that's the reason nobody seems to have been around to know about.
>> It just sounds like it /could/ be dangerous to me. For some reason, I
>> don't like the idea of something that could hose a system that badly! =8^\
>
> *Please* don't tell me you run ~arch.

Well, I do, plus some stuff from package.mask like gcc-4.x and the
associated binutils and glibc stuff.

OTOH, I have long run a working and a backup snapshot version of the
system portions of my system (everything that packages normally touch),
for this very reason -- I'm running unstable, so I should be prepared to
boot to the backup if the main system gets hosed, either by my
fat-fingering or that of someone else.

Still, the last glibc upgrade was more "exciting" than I had anticipated,
even if DO say if I wanted boring and reliable, I'd be doing household
appliances, not computers. <g> (I'm proud to say I handled it without
having to resort to a reboot or the backups, tho... if only because I
happened to have an mc instance running in another vt at the time, and I
was able to use it to restore enough symlinks manually, to read the
documentation, figure out what happened, and restore the others by copying
them out of the binpkg.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list