Re: [A-A-P-develop] On the dangers of PKGNAME=.
Brought to you by:
vimboss
From: Bram M. <Br...@mo...> - 2003-10-24 17:42:20
|
Adriaan de Groot wrote: > On Thursday 23 October 2003 23:10, you wrote: > > Adriaan de Groot wrote: > ]> > ./share/apps/kpilot/sysinfoconduit/Template.html > > > ./share/apps/kpilot/sysinfoconduit/Template.txt > > > ./share/services/sysinfo-conduit.desktop > > > > > > (and several more). > > > > In this situation I would set $PKGNAME to "apps/kpilot" and add the > > files under it to $INSTALL_DATA. For the other files under "share" add > > a new install target "install-local". That's what it is for. > > Heh, given that more things get installed into "services" than into > "apps/kpilot" by this particular recipe, then I'd set PKGNAME to "sevices" -- > which really makes no sense. It gets worse when stuff also goes into "icons" > and "wallpapers" and "doc". Thing is, it could work so simply, if only AAP > would let PKGNAME be "" (or "."). > > > A compromise could be to make a difference between an empty $PKGNAME and > > not setting $PKGNAME. It's subtle, but it makes sure that the user sets > > $PKGNAME, so that he (hopefully) knows what he is doing. > > Well, PKGNAME= vs. PKGNAME=. is hardly more visible, both are subtle. > I'm inclined to say that PKGNAME=. is better because no AAP code needs > to change, just Python bugs fixed. I think that "." is not a valid package name. Therefore $PKGNAME should not be set to ".". That you know how it works internally is not a good argument to start using ".". Well, I think allowing an empty $PKGNAME is the best solution. The patch is simple. In default.aap: 579c579 < @if not _no.get("PKGNAME"): --- > @if _no.get("PKGNAME") == None: 584c584 < @if not _no.get("PKGNAME"): --- > @if _no.get("PKGNAME") == None: > > I consider this a bug in os.makedirs(). Would you want to post a bug > > report for this or should I do it? > > You do it please. OK. > > The problem is that the recursive implementation of makedirs() only > > checks for existence of the dir before going recursive. It doesn't > > check again after the recursive invocation. It should either do another > > exists() or skip "." directories. > > That would also make it susceptible to race-conditions causing makedirs() to > throw exceptions weirdly. It's certainly susceptible to race conditions. But that would hardly ever be a problem. -- A computer programmer is a device for turning requirements into undocumented features. It runs on cola, pizza and Dilbert cartoons. Bram Moolenaar /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html /// |