syms_not_owned() causes symlinks to become alien #34

Merged
merged 1 commit into from Jan 16, 2013

Conversation

Projects
None yet
3 participants
Owner

Ratler commented Dec 2, 2012

If a module create a symlink to a file that belong to another
module the core tools stripped these links from the install log
leaving the symlinks alien in the system. This proposal fix that
minor issue.

@Ratler Ratler syms_not_owned() causes symlinks to become alien
If a module create a symlink to a file that belong to another
module the core tools stripped these links from the install log
leaving the symlinks alien in the system. This proposal fix that
minor issue.
43bd964
Member

cavalier38 commented Dec 2, 2012

There is also a symlink check in lunar fix which does this: check-symlink.lunar
I'm not sure if this includes conditions where two modules own the same symlink, but in those cases the symlink could be removed where is should not, but lunar fix might solve that.

sofar was assigned Dec 14, 2012

Owner

Ratler commented Dec 14, 2012

Auke, mind having a look at this? This change is necessary for some modules to properly track files for the new ISO.

Owner

sofar commented Dec 14, 2012

this code should probably never be needed, but which links are actually an issue?

also, links disappearing is worse than a few alien links on the filesystem, so I'm still a bit worried about this. If you have identified all the problematic links we should see about fixing these duplicates first. After that, this code can go.

Owner

Ratler commented Dec 14, 2012

The case where we actually noticed the issue is with systemd-sysv which creates sysvinit compatible links against systemdctl. So it's not an duplication issue.

Owner

sofar commented Jan 16, 2013

ok, let's go test this code for a bit.

sofar merged commit 5c5b927 into lunar-linux:master Jan 16, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment