nothing against modules on the server but i'd like to see the update scripts continue...
the failure occurs in a fairly specific use case afaics..
ie. if flash* is previously installed in save.dat or module that isnt named flash* , therefore not deactivated..
(not least deactivating general changes would undesirable)
im no script wizard, but would think this situation is detectable
and at the least, a "Hey, you need to clean out your changes.dat/module, before continuing,so on" type message..
and/or simply the option of diverting to downloading the prebuilt module..
*or browser/program
Porteus 3.2 and Firefox/Flashplayer problem
- ncmprhnsbl
- DEV Team
- Posts: 3938
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
Re: Porteus 3.2 and Firefox/Flashplayer problem
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
Re: Porteus 3.2 and Firefox/Flashplayer problem
I think this is where the problem lies. Not just flash, but firefox also, for example. I guess even USM installs the package/packages first and then creates an xzm module out of it. What this means is if the user had changes turned on when installing, the install is automatically reflected in his save.dat. On a later date, upgrading the same package which requires a removal of older files of that package would naturally cause whiteouts in the save.dat.ncmprhnsbl wrote:if flash* is previously installed in save.dat
For me, a package installation should not be reflected on a save.dat. It should only go into the live system as a module.
Agree. As a sanity check, could still be done. (Maybe user had installed firefox directly using installpkg previously when save.dat was on.)ncmprhnsbl wrote:im no script wizard, but would think this situation is detectable
and at the least, a "Hey, you need to clean out your changes.dat/module, before continuing,so on" type message..
and/or simply the option of diverting to downloading the prebuilt module..
*or browser/program
-
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Re: Porteus 3.2 and Firefox/Flashplayer problem
ExtrapolatingBogomips wrote:
- After doing fastest-server( really convenient)
- Check if version on server is latest, and if so just downoad it
- Otherwise give user option of a direct download of version on server or building latest version module.
Run, say, a weekly cron job with self as user, uploading to the server latest version update script build, where relevant. Then there is option of pre-built module, pre-built latest version update script build (where applicable), or build from scratch, for paranoic or other reasons. 8)
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: Porteus 3.2 and Firefox/Flashplayer problem
Ok so what I am hearing is this:
1) First check if latest version IS the module on the server .. download.
2) If latest version is not on server offer to build.
3) If firefox/flash is installed warn user to cleanup save.dat file
IMHO it is difficult to accommodate ALL scenarios. As mentioned, user may have built firefox/flashplayer on their own and installed using slackware tools. In this case slackware tools needs to be used to remove it which will leave whiteout files.
1) First check if latest version IS the module on the server .. download.
2) If latest version is not on server offer to build.
3) If firefox/flash is installed warn user to cleanup save.dat file
IMHO it is difficult to accommodate ALL scenarios. As mentioned, user may have built firefox/flashplayer on their own and installed using slackware tools. In this case slackware tools needs to be used to remove it which will leave whiteout files.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
- Ed_P
- Contributor
- Posts: 8369
- Joined: 06 Feb 2013, 22:12
- Distribution: Cinnamon 5.01 ISO
- Location: Western NY, USA
Re: Porteus 3.2 and Firefox/Flashplayer problem
I would check if the module on the server is newer than the one the user is running. If so .. download.brokenman wrote:Ok so what I am hearing is this:
1) First check if latest version IS the module on the server .. download.
2) If latest version is not on server offer to build.
If the module on the server is the same as the one the user is running then offer to build the latest.
I don't agree with this approach. If the update doesn't delete the existing module there should be not need to do this. If the update replaces an existing version the updated changes will replace the files in the save.dat also.3) If firefox/flash is installed warn user to cleanup save.dat file
BTW My save.dat only gets updated when I shutdown. But the updated flash module not working occurs as soon as the update-flash finishes. The save.dat files have no impact on this.
I think the users that do that are a. a very small percentage of the user base and b. are smart enough to know that removals cause whiteouts. If you want to make their whiteout cleanup easier create a script of remove the whiteout files that I listed previously. And if concerns for whiteouts in the save.dat file have the script run automatically when the user is shutting down. Similar to how USM whiteouts are handled.IMHO it is difficult to accommodate ALL scenarios. As mentioned, user may have built firefox/flashplayer on their own and installed using slackware tools. In this case slackware tools needs to be used to remove it which will leave whiteout files.
Ed
-
- Full of knowledge
- Posts: 2070
- Joined: 17 Jun 2013, 13:17
- Distribution: Porteus 3.2.2 XFCE 32bit
- Location: Germany
Re: Porteus 3.2 and Firefox/Flashplayer problem
C'mon guys
The porteus way to handle software is to use modules,period.
1st premise = Browsers without flash = no wh files when using a newer flash version (module)
afaics de-/activate a flash module does not produce any wh files.
Like any other Linux porteus has "its" Repositories, (USM), so you will most likely
find what you're looking for.
If one wants to build software from packages found somewhere next to the moon you're
on your own -- As with any other linux distribution.
The update script - how does it work -
It downloads the source package and then utilizes a slackbuild script.
Everyone knows compiling software, even with the help of a slackbuild script can
go wrong.(leaving wh files)
Therefore please, please do it in "always fresh".It avoids to alter the save-file.
If all goes well, you got a module for further use.(the porteus way).
at the end, if you want to compile a flash version which is not in the Repo yet,
do it at your own risk -- no Dev should be responsible for that.
imho, the update script should only look at the server and give a hint when there is a newer
prebuilt Flash MODULE. 8)
The porteus way to handle software is to use modules,period.
1st premise = Browsers without flash = no wh files when using a newer flash version (module)
afaics de-/activate a flash module does not produce any wh files.
Like any other Linux porteus has "its" Repositories, (USM), so you will most likely
find what you're looking for.
If one wants to build software from packages found somewhere next to the moon you're
on your own -- As with any other linux distribution.
The update script - how does it work -
It downloads the source package and then utilizes a slackbuild script.
Everyone knows compiling software, even with the help of a slackbuild script can
go wrong.(leaving wh files)
Therefore please, please do it in "always fresh".It avoids to alter the save-file.
If all goes well, you got a module for further use.(the porteus way).
at the end, if you want to compile a flash version which is not in the Repo yet,
do it at your own risk -- no Dev should be responsible for that.
imho, the update script should only look at the server and give a hint when there is a newer
prebuilt Flash MODULE. 8)
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: Porteus 3.2 and Firefox/Flashplayer problem
This assumes the user only uses modules and hasn't installed a slackware package while using a changes= cheatcode. It is generally not a good practice to go compounding installs over the top of each other.I don't agree with this approach. If the update doesn't delete the existing module there should be not need to do this.
Another factor that complicates automation. This is why I would prefer to leave the decision of any removals to the user.BTW My save.dat only gets updated when I shutdown.
I disagree here. I'm not sure of percentages at all, but I am absolutely certain that very few people understand the job of a whiteout file on a union file system.I think the users that do that are a. a very small percentage of the user base and b. are smart enough to know that removals cause whiteouts.
This will never happen. Whiteout files are like a turd in the bush. Best leave them alone and let nature sort it out.If you want to make their whiteout cleanup easier create a script of remove the whiteout files that I listed previously.
This would be ideal, but it is not realistic. Porteus is a slackware based system that pulls slackware packages from a slackware repository. I would love it if every user only downloaded and activated modules, but the reality (i believe) is different. And we will be answering the questions as to why, unless we decide that only Porteus compliant modules are supported. I like this idea. .wh files give me a rash.The porteus way to handle software is to use modules,period.
1st premise = Browsers without flash = no wh files when using a newer flash version (module)
afaics de-/activate a flash module does not produce any wh files.
By "its" repositories I think you mean slackware's.Like any other Linux porteus has "its" Repositories, (USM), so you will most likely find what you're looking for
In the end, this is the most sensible thing I have heard. Much less complicated. Much less hassle.imho, the update script should only look at the server and give a hint when there is a newer prebuilt Flash MODULE.
If your not using modules, or if you are compiling your own stuff, then you can sort out the consequences. The best scripts (from my point of view) are the least invasive ones.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.