bugGNU Stow - Bugs: bug #558, CONFLICTS when a programm has man...

 
 

bug #558: CONFLICTS when a programm has man pages

Submitted by:  Invalid User ID <Invalid User ID>
Submitted on:  Fri 07 Jun 2002 08:59:04 AM UTC  
 
Category: NoneSeverity: 2 - Minor
Item Group: NoneStatus: None
Privacy: PublicAssigned to: Guillaume Morin <gmorin>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 10 Jan 2012 11:56:17 AM UTC, comment #5:

Stow has been substantially rewritten since this report, and now has a comprehensive test suite. If anyone can reproduce this behaviour please reopen and provide steps to reproduce, otherwise I am considering it fixed.

Note that the info dir issue is entirely separate, and cannot be resolved via stow because it involves changing the contents of files, which stow will never do (with the single exception of the new --adopt option in 2.1.3).

Adam Spiers <aspiers>
Project Administrator
 Spam posted by an anonymous
Thu 21 Oct 2004 08:08:59 PM UTC, comment #4:

for finds "they" are different, read finds "the source and target paths" are different, thankyou. Why should stow expect them to be the same ? As long as there is no conflict in filestore items, why can't the target path be symlinked elsewhere ? I've spent too much time staring at code lately else I'd debug it further myself %-)

Nick Leverton <leveret>
Thu 21 Oct 2004 07:57:31 PM UTC, comment #3:

If anyone is still reading this bug, I can confirm it happens and help debug it. I stuck some print statements in, and found that it fails because, in subroutine StowDir,
this statement:

($linktarget = readlink(&JoinPaths($Target, $subdir)))

expands the target link, and then this one:

&FindStowMember(sprintf('%s/%s', $Target,
join('/', @dir[0..($#dir - 1)])),
$linktarget))

finds they are different and in the next statement bails out. However I don't know what the logic should be !

Nick Leverton <leveret>
Sun 01 Aug 2004 09:03:09 PM UTC, comment #2:

I've encountered the same error, however in my case,
/usr(/local)/man is soft linked to /usr(/local)/share/man
(for fhs compliance).

Also, when stowing packages that include info files,
there's always a conflict with the
/usr(/local)/share/info/dir file, since the dir file needs
to be appended, not replaced. Is there an easier way
around this, other than manually editing the dir file?

Anonymous
Fri 06 Dec 2002 01:46:45 PM UTC, comment #1:

Hi,

Could you send me the output of 'ls -l /usr/local/man' ?

Guillaume.

Guillaume Morin <gmorin>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by aspiers (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 10 Jan 2012 11:56:17 AM UTCaspiersOpen/ClosedOpen=>Closed
    Thu 21 Oct 2004 07:57:31 PM UTCleveretCarbon-Copy-=>Added nick --AT-- leverton --DOT-- org
    Fri 06 Dec 2002 01:46:45 PM UTCgmorinSeverity3 - Normal=>(Error - Not Found)
      Assigned toNone=>NA

    Back to the top


    Powered by Savane 3.1-cleanup1