1 |
On Friday 23 December 2005 22:13, Harald van Dijk wrote: |
2 |
> On Fri, Dec 23, 2005 at 10:00:20PM +0900, Jason Stubbs wrote: |
3 |
> > On Friday 23 December 2005 21:39, Harald van Dijk wrote: |
4 |
> > > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote: |
5 |
> > > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote: |
6 |
> > > > > Well, you should know that those are because of portage bugs or |
7 |
> > > > > some portage peculiarity, read the corresponding bugs for example |
8 |
> > > > > for cups to find out more. |
9 |
> > > > |
10 |
> > > > Can you point me to a bug? There's no mention in the ChangeLog that I |
11 |
> > > > can see nor in the ebuilds themselves... |
12 |
> > > |
13 |
> > > Bug #99375 is mentioned in the changelog for samba. |
14 |
> > |
15 |
> > Okay. It appears to be something related to symlinks. Can you show me the |
16 |
> > bug assigned to portage that reports this and/or shows how to reproduce |
17 |
> > it? |
18 |
> |
19 |
> Don't know if it's been reported as a portage bug, but this would show |
20 |
> it: |
21 |
> |
22 |
> KEYWORDS="~x86" |
23 |
> src_install() { |
24 |
> dodir /test |
25 |
> dosym /usr/bin /test |
26 |
> } |
27 |
> |
28 |
> When unmerging, portage won't remove /test/bin because its target still |
29 |
> exists. |
30 |
|
31 |
Seeing that there's no bug filed for this, discussion can go here; that's no |
32 |
existance of a portage bug is of itself no reason to put an ugly workaround |
33 |
in the ebuilds themselves mind you. |
34 |
|
35 |
Symlinks are handled within portage differently to regular files. Regular |
36 |
files get an mtime check and are removed if it matches. Symlinks don't get an |
37 |
mtime check (even thought the mtime is stored) and are only removed if the |
38 |
symlink's target doesn't exist. Hence, it seems to be this way by design. Why |
39 |
it's this way? Who knows. It's been that way for longer than anyone can |
40 |
remember which is why _it's so important that bugs get filed_. |
41 |
|
42 |
A quick patch makes symlinks handled similarly to regular files and solves the |
43 |
issue. I'll put it into testing unless anybody can come up with a reason not |
44 |
to. The case that will be broken by the patch is when two different packages |
45 |
install the same symlink. PackageA is installed, PackageB is installed, |
46 |
PackageB is uninstalled -> PackageA is broken. Does this case exist? |
47 |
|
48 |
-- |
49 |
Jason Stubbs |
50 |
|
51 |
-- |
52 |
gentoo-dev@g.o mailing list |