The Testing Area :: Declobbered



Quote
You mean that do exist ;)
Yes, exactly.  It's opposite day.

Quote
But I don't see the need for that directory to be included in this case
I don't know what the case is exactly, but I suppose it's probably easier to do the thing that occured to me at the end of my rant...creating a directory from a wrapper script.  If it's a uci or unc, the "directory" could be included in the package as a symlink to /opt/something_else, which would be writable.
I'll look at this issue again tomorrow when I'm awake.

However I'm pretty sure I had it right the first time. The goal of the script is to help prevent extensions breaking the system or other  extensions.  As I recall the policy wasn't  about being a "bully";  it was about the script not being able to tell whether an empty directory could potentially clobber files in eg some other unknown extension having the same non-system directory.  In that case, it's a bad coyote, and I prefer a risk management approach to letting through hanging empty directories in *any* part of the writeable filesystem, with unpredictable results when installed over other extensions.

How many extensions have non-base empty directories anyway that are actually supposed to be there and that do anything at all? One in 200? The vast majority shouldn't be there.  So I erred on the side of caution.

It's not a replacement for the extension builder's brain (I wish), it's just a simple coarse filter for badly built extensions, and you should preferably check/test its results, which is why this thread is here. That's also why the file lists are left in the working directory.  You can always put an empty directory back.  After all, you built the extension in the first place.

But as I said, I'll give it some more thought and suggestions are welcome.
Quote
How many extensions have non-base empty directories anyway that are actually supposed to be there and that do anything at all? One in 200? The vast majority shouldn't be there.  So I erred on the side of caution.
I totally agree. I know I have seen at least one application which for some reason got angry when it was missing an empty directory.  I can't remembr if it failed to launch, or if it merely spit out some nasty words. But after second thoughts, it seems more logical to stick with simplicity. Declobber fully and without prejudice. If the package builder needs an empty directory for some dumb reason, she should create it at first runtime. Also, putting more emphasis on declobbering would probably be good, such as making it a requirement in the *.dsl and *.tar.gz extension-building process. Well, maybe not a requirement, but something like "If you don't know what declobbering does, you should probably run the script".
Based on the discussion in this thread from our most knowldgeable users, it would appear to be a better solution for me to post the declobbered .dsl extensions. From said discussion the number of issues would be dramatically reduced. As only those extensions that acutally needed an empty directory would fault. As it is now, many .dsl extensions, as pointed out by user, jls, crash the system
The declobbered extensions have been moved into their respective directories. Hopefully this will end the issue of clobbered systems.

Thanks for the feedback/discussion.
Next Page...
original here.