First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 149745
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Portage team <dev-portage@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: brad walker <bradmwalker@cableone.net>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
dohtml.patch dohtml.patch patch brad walker 2007-01-08 01:05 0000 2.70 KB Details | Diff
dohtml.patch dohtml.patch patch brad walker 2007-01-08 14:18 0000 5.01 KB Details | Diff
dohtml.patch dohtml.patch patch brad walker 2007-01-11 01:41 0000 4.94 KB Details | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 149745 depends on: Show dependency tree
Bug 149745 blocks: 216231
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2006-10-01 09:33 0000
Portage version 2.1.2_pre2

call dohtml without argument '-r' on a directory and it will fail silently when
it tries to install the directory. 

IMO, skipping the directory is better behavior. try 'dohtml doc-html/*' and
dohtml will install only the files before the first subdirectory, ordered
alphabetically. it'd be more intuitive for dohtml to install all the files,
skipping directories.

optimally dohtml could filter all files and directories into different arrays,
processing files first, then directories. then dohtml could install all files,
and return false when given directories without the '-r' argument. authors
would have the intuitive behavior and be able to debug using lines like 'dohtml
doc-html/* || die "directories need -r"'.

------- Comment #1 From brad walker 2007-01-08 00:57:52 0000 -------
this line in main:/usr/lib/portage/dohtml causes the problem:
               success = success and install(basename, dirname, options)

as soon as install fails once the 'for x in args' loop never installs again.
the python keyword 'and' prevents `install' execution after `success' is false.
`install' returns false on a directory without options.recurse, causing the
problem originally described.

------- Comment #2 From brad walker 2007-01-08 01:05:22 0000 -------
Created an attachment (id=105973) [details]
dohtml.patch

Changes:
  added QA Notice for directories without recursion
  fixed main driver loop ('success &= install' instead of 'success = success &
install')
  misc. cleanups

------- Comment #3 From brad walker 2007-01-08 14:18:34 0000 -------
Created an attachment (id=106027) [details]
dohtml.patch

same as last with indentation fixed

------- Comment #4 From Zac Medico 2007-01-08 15:26:39 0000 -------
Instead of using the output module for the ewarn, I suppose we should spawn
something like `bash -c 'source ${PORTAGE_BIN_PATH}/isolated-function.sh; ewarn
"QA Notice:..."'` so that it works correctly with the elog framework.  Note
that soon we'll have a QA elog level for bug #160075.

------- Comment #5 From brad walker 2007-01-11 01:41:01 0000 -------
Created an attachment (id=106478) [details]
dohtml.patch

Changes:
  use new eqawarn function from isolated-functions.sh (tested with svn
isolated-functions.sh)

------- Comment #6 From Zac Medico 2007-01-14 05:15:42 0000 -------
Thanks.  In svn r5642 I've fixed it so that it continues to install files even
after some fail.  I'll wait until after the final release of 2.1.2 (coming
soon) for the QA warning since I'm not sure how many packages it will affect
and people will get upset if it produces any warnings that they see as invalid
or unnecessary.

------- Comment #7 From brad walker 2007-01-24 04:31:44 0000 -------
cool beans.

please (re)consider the latest proposed patch. it includes many cleanups:
whitespace, expressions, and comments.

the main loop fix applied in svn r5642 is excessively verbose compared to the
patch's fix. again, the misuse of keyword 'and' vs. operator '&' caused the
original problem. simply substituting '&' for 'and' fixes the error; using '&='
simplifies the statement further.

------- Comment #8 From Jakub Moc (RETIRED) 2008-02-17 21:02:52 0000 -------
Is this bug still even remotely relevant with current portage versions?

------- Comment #9 From Arfrever Frehtes Taifersar Arahesis 2008-03-20 18:01:02 0000 -------
Fixed in r9476 and released in sys-apps/portage-2.2_pre5.

This bug should be RESOLVED FIXED and block bug #210077.

------- Comment #10 From Marius Mauch (RETIRED) 2008-03-20 18:14:50 0000 -------
This is supposed to be fixed in portage-2.2_pre5 or earlier.

------- Comment #11 From Marius Mauch (RETIRED) 2008-03-20 18:15:27 0000 -------
This is supposed to be fixed in portage-2.2_pre5 or earlier.

First Last Prev Next    No search results available      Search page      Enter new bug