Porteus

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

ncmprhnsbl wrote:if flash* is previously installed in save.dat

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.

For me, a package installation should not be reflected on a save.dat. It should only go into the live system as a module.

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

Agree. As a sanity check, could still be done. (Maybe user had installed firefox directly using installpkg previously when save.dat was on.)

Bogomips 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.

Extrapolating
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)

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.

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.

I would check if the module on the server is newer than the one the user is running. If so .. download.
If the module on the server is the same as the one the user is running then offer to build the latest.

3) If firefox/flash is installed warn user to cleanup save.dat file

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.

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.

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.

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.

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)

I don't agree with this approach. If the update doesn't delete the existing module there should be not need to do this.

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.

BTW My save.dat only gets updated when I shutdown.

Another factor that complicates automation. This is why I would prefer to leave the decision of any removals to the user.

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.

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.

If you want to make their whiteout cleanup easier create a script of remove the whiteout files that I listed previously.

This will never happen. Whiteout files are like a turd in the bush. Best leave them alone and let nature sort it out.

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.

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.

Like any other Linux porteus has "its" Repositories, (USM), so you will most likely find what you're looking for

By "its" repositories I think you mean slackware's.

imho, the update script should only look at the server and give a hint when there is a newer prebuilt Flash MODULE.

In the end, this is the most sensible thing I have heard. Much less complicated. Much less hassle.
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.