Originally Posted by woody14619

You mean the one that you edit almost daily? Yes... I did. You note there that you load a profile called overclock about 3-pages down in the first post. But it's not highlighted, just in plane simple text, and most people won't read that far simply because of all the technical crap and jargon you have before it.

Line one of that top post should read, in clear bright bold letters "BatteryPatch uses kernel Overclocking, and overclocks your device." The same warning should be in the description of the package.

We're not talking about the potential to overclock (like KP, which has such warnings), or that you can change settings to enable overclock, like other apps that overclock (which all have said warning). There's no clear and concise notice that you're overclocking their device (as witnessed by at least one person posting that it was not obvious to them.)

There's also no notice at all that you're enabling a very unstable, still in testing setting (SR1), that may cause system instability. There's also no indicator that you're overclocking with min frequency set >700Mhz, which is beyond bogus, even for a short time, yet alone a full call.



I do... Your deb package replaces existing files, after renaming the originals as a "backup". If another package sets a variable in .profile (like say SET MAADE_ENV=N900), your postinst moves that to a backup file and replaces the .profile with your settings. Now any package that put stuff into the .profile the right way will cease to function. And if they uninstall speedpatch, it doesn't restore the backup, leaving that application still broken! THAT'S A PERMANENT SYSTEM CHANGE, why can't you understand that simple fact?



It's not *harder* that you need to explain it. The way you're doing this is simply wrong. Period. When dealing with shared resource files (like .profile) you can't just replace them with your content. You must inject the content, and remove it when you're done. Look at deb files from any other debian-based distro system and you'll see them doing that.



YES! Because you're doing it WRONG! I told you why you were getting that message. In fact, I can show you exactly how to reproduce that message:

• Edit your .profile and add a simple line: SET FOO=1
• Now run the package reconfigure command. The .profile with SET FOO is moved to .profile.speedpatch and your package profile is put into .profile.
• Now run that reconfigure again. SET FOO is now completely GONE. And if you were to restore during uninstall, you'd get a copy of your package's .profile, which is what's generating the error you were seeing!

The solution here is not to just not restore the files. The solution is to FIX YOUR DAMN STUPID INSTALLER SCRIPT so that you don't over-write an existing backup file! Minimally, all you would have to do is this:

Code:

if [ ! -e /home/user/.profile.speedpatch.bak ]; then
mv /home/user/.profile /home/user/.profile.speedpatch.bak 
fi

See those two red lines? That's all you have to add to accomplish the ability to restore the original file. If a backup pre-exists on the users system, don't overwrite it. Basic scripting rules. Done... two lines, but that's apparently too hard for you to figure out?

The correct way to do this, is to inject your script block into the .profile in postinst, like this:

Code:

echo "#Next X lines are from SPEEDPATCH" >> /home/user/.profile
echo "echo $$ >/dev/cgroup/.....  " >> /home/user/.profile
...

Then in your prerm, you can use sed to find your tag (SPEEDPATCH) and remove that line and the X below it from .profile. Done. It's that freaking simple. You could even use grep to remove them, since they all contain the word speedpatch! Like this:

Code:

cp /home/user/.profile /home/user/.profile.sp.uninst
grep -v -i speedpatch </home/user/.profile.sp.un >/home/user/.profile

Is that so complex? Clearly too much you to understand and fix, I mean this is tough scripting code... not nearly as easy as scripting an entire system to add in cgroups, right? Instead, you'd rather break other people's installs by replacing the .profile with your own stuff, to hell with anyone else.



Because noob users will totally know if any package they've already installed has a .profile change? Nope. And they will have a problem with it, because YOUR PACKAGE DOESN'T RESTORE THE BACKUP FILES ON UNINSTALL!

Want to see an example of a noob who's system broke because of your speedpatch? There's lots of them in threads you've already read. Trish02 for example.



I DID... You know what?
IT WAS OVER CLOCKED THE WHOLE CALL!

Maybe you should take your own advice? Underclock profile is not loaded during the call. It's loaded after the call finishes, after the user has hung up. The whole time the call is going on, it has the overclock-call profile loaded.

You may have some special version on your device that doesn't. But the one in the repository overclocks for the duration of the call. I quoted the very line of script that showed you exactly where the error was. Did you think I didn't ssh into my device to get that? Where did you think it came from?



There are KP versions from the 30s on up, which have all been in the repository at some point. Just because they're not in the repository as the default item today doesn't mean they never existed. There are lots of people out there running PR1.1 still! Did it not occur to you that someone may still be running KP38, or KP41, or KP43? Did you think they just randomly skipped release numbers?

If you rely on a specific version of a package, you should be putting that in the dependency settings for your package. It's quite easy to do! You just specify you require KP49 or better, and viola, it will either install the newer version, or refuse to install your package because it can't get the latest KP.

The repeating point here is you're doing things wrong. The proper way to do this is to assume they have a system/kernel that is older and can't handle SR1. Then test for the version by number and copy the SR1 enabled file into place only when you have determined it can be used by the kernel on the system. You're doing the opposite, which will cause *lots* of people's systems to break when they install your package. All because you couldn't be bothered to properly, logically think about this and do it the right way.



You're assuming a lot. You're assuming someone is coming to this thread, and reading the entire first post. First off, lots of people just install things from the repository based on the description of the package. Nowhere in the description do you say you're overclocking. And then, even if they find this thread, most people won't read that enormous first post! After the first page of speedpatch technical lies (btw, you still never addressed how you lie about making 3 cgroups when you really only make 1!), most will go "yeah yeah! it tweaks things.. next page". They won't make it to the battery patch section, where you mention you load an overclock profile way down in the mumbo-jumbo techincal details. And even there, you're never telling people how drastically you're overclocking!



Yes... you did entirely miss my point about how you're doing it in the completely wrong way. And that the error you get on uninstall was caused by your lack of doing backups correctly. That the warning you were getting was caused entirely by your inability to think logically or write two lines of script to check to see if you already did that step.



Take your own advice.



And I'll note again: Most people don't read FAQ or posts. There are third party site (like mymaemo.com) that link to the repositories here, and offer NO details about where to find this forum, or your FAQ, or this thread! People installing from there rely on the package description to tell them information.



What? That you rolled a new version, and didn't put it into the repository? That's wonderful... Frankly I'm not inclined to got get it and dissect it again. Why bother? So I can point out more errors in your scripts? It's all pretty much crap. Why would I want to do this whole thing over, when the clear point has already been made:

You have no idea what you're doing, and you lack even the basic scripting talent to make a proper install/uninstall package for a set of shell scripts. If you can't even get the install scripts right (which are only like 4 or 5 lines of script), what confidence should I have that all the other scripts you wrote for these packages are any better? Or that I should let you make new scripts every other day to run on my device, breaking it in random ways? No, thanks...



That's great. Tell me, can you explain why any of that happened? You clearly don't even know what you're doing, since you claim to have made 3 separate cgroups, when the script you posted only creates 1!

Be sure to document which of the 500 versions of speedpatch you released that he tested. And also note that you still leave permanent system changes when you install and uninstall.

Again: I never said these patches do nothing. I said they made permanent changes than an uninstall didn't undo, which is true. I also said they don't do anything that would seem cause anything but shell scripts to speed up. And since you've yet to even being to explain how or why the single additional cgroup (not groups, group, you make 1, not 3) do anything at all, there's little to talk about on that topic.