l2ulinux, First, please try 004 in the first message of this thread. If the problem persists then try Menu -. Internet -> Frisbee Network Manager Install.l2ulinux wrote:First 528 worked good, 002M when I did a save to CD are made a savefile I lost the use of the keyboard and with 003 it turns my ethernet off and it will not work again with any Puppy are windows till I shutdown the system. Then I have to unplug the ethernet csble and put it back in.
Lucid Puppy 5.2.8 - Updated ISO Version 005 - APR 05 2012
Re: 5.2.8
- cowboy
- Posts: 250
- Joined: Thu 03 Feb 2011, 22:04
- Location: North America; the Western Hemisphere; Yonder
torrents and releases
Torrents might be good during these new releases. Ibiblio is downloading this evening at about 34, even diddywah is around 40, tried aaarnet (the repository for Pirates, matey), even worse. The iso would take over an hour to pull down. (which really, when you think about speeds ten years back, ain't that bad). But I want to whine, and I'm gonna. It appears the original torrent creator must be hooked to internet 24/7? Is that right? Might be something we could put on forum somewhere? Especially with the ever increasing popularity of the Pup.
EDIT: bit here on torrents for Puppy
http://murga-linux.com/puppy/viewtopic.php?t=72863
Back to the holiday cheer....
EDIT: bit here on torrents for Puppy
http://murga-linux.com/puppy/viewtopic.php?t=72863
Back to the holiday cheer....
[i]"you fix what you can fix and you let the rest go.."[/i] - Cormac McCarthy - No Country For Old Men.
At last, another patch (6) for sound issues
Playdayz & others interested,
Here is the long-promised patch with my best shot at solving the sound issue without changing the original design. It is intended for Instant Update 002 through Lucid 5.2.8-004 (so far). The primary changes for the flash-drive save layer:
The conflicting situations will require a reboot to trigger saving to flash drive between installations and uninstallations. Ideally, you should be able to uninstall, then save, then install, all in the same session. But this is not possible due to a problem with the package installer. It must be completely terminated in order for a "save" to be performed. But the installer/uninstaller does not terminate completely, leaving its main process executing, even though its dialog window is closed by the "Exit package manager" button. I need a gtkdialog expert to resolve that before we can implement the all-in-one-session mode of operating.
EDIT: To clarify how the conflict prevention works, it merely instructs the user to reboot if a conflict among packages is possible. Having disabled automatic saving, I do not want to save as an invisible part of the package manager/petget. In general, it is safest to change packages as the only activity in a session, to avoid the possibility of accidentally modifying package components.
The installation of this package is a little unusual. Normally in the flash-drive environment, if a file has been uninstalled, the older version will remain functional until a reboot. In the patch package, the package manager and snapmerge components are copied to the top layer, to make them functional immediately. In case the package is uninstalled then reinstalled, the uninstallation script restores those components, to retain the new control of uninstall-save-install sequences. Therefore, use an expendable setup for early testing.
This package is consistent with the woof/wary design, by working only with /dev/snd for the sound issue. If that is still insufficient, it may support arguments for expanding special treatment in the /dev directory.
Here is the long-promised patch with my best shot at solving the sound issue without changing the original design. It is intended for Instant Update 002 through Lucid 5.2.8-004 (so far). The primary changes for the flash-drive save layer:
- - Removes /dev/snd, /dev/mixer & /dev/ttyUSB* files during initialization, as in wary.
- Disables automatic saving by setting the save interval to zero in /etc/eventmanager file; user can change that file to activate (possibly risky) automatic saving.
- Prevents conflict among installer, uninstaller and save snapper that could corrupt an installation.
- Allows user to choose to be asked whether to save during shutdown, by setting "ask" in the /etc/shutdown_save_mode file.
- Corrects/activates jemimah's removal of the actual file represented by a whiteout.
- Creates parent directories for whiteouts if needed for storing them.
- Cleans files out of the save layer for /dev/snd only, leaving only the whiteouts.
- Processes whiteouts for /pinstall.sh, /puninstall.sh & /pet.specs (from package installations); whiteouts for other top (/) level files are not retained, per design.
The conflicting situations will require a reboot to trigger saving to flash drive between installations and uninstallations. Ideally, you should be able to uninstall, then save, then install, all in the same session. But this is not possible due to a problem with the package installer. It must be completely terminated in order for a "save" to be performed. But the installer/uninstaller does not terminate completely, leaving its main process executing, even though its dialog window is closed by the "Exit package manager" button. I need a gtkdialog expert to resolve that before we can implement the all-in-one-session mode of operating.
EDIT: To clarify how the conflict prevention works, it merely instructs the user to reboot if a conflict among packages is possible. Having disabled automatic saving, I do not want to save as an invisible part of the package manager/petget. In general, it is safest to change packages as the only activity in a session, to avoid the possibility of accidentally modifying package components.
The installation of this package is a little unusual. Normally in the flash-drive environment, if a file has been uninstalled, the older version will remain functional until a reboot. In the patch package, the package manager and snapmerge components are copied to the top layer, to make them functional immediately. In case the package is uninstalled then reinstalled, the uninstallation script restores those components, to retain the new control of uninstall-save-install sequences. Therefore, use an expendable setup for early testing.
This package is consistent with the woof/wary design, by working only with /dev/snd for the sound issue. If that is still insufficient, it may support arguments for expanding special treatment in the /dev directory.
- Attachments
-
- lupu528-IU002_rerwin_patch-6.pet
- Mods to patch-5 to improve sound issue. Be sure to reboot after installing this.
- (125.64 KiB) Downloaded 465 times
Last edited by rerwin on Wed 21 Dec 2011, 16:40, edited 2 times in total.
Re: torrents and releases
Since I hadn't downloaded 004 yet......I checked Ibiblio and was downloading at about 75 kB/s and I'm downloading now from diddywahdiddy at 130-140 kB/s ... both a bit slower than normal but not too bad. FWIW.cowboy wrote:Torrents might be good during these new releases. Ibiblio is downloading this evening at about 34, even diddywah is around 40, tried aaarnet (the repository for Pirates, matey), even worse. The iso would take over an hour to pull down. (which really, when you think about speeds ten years back, ain't that bad). But I want to whine, and I'm gonna. It appears the original torrent creator must be hooked to internet 24/7? Is that right? Might be something we could put on forum somewhere? Especially with the ever increasing popularity of the Pup.
EDIT: bit here on torrents for Puppy
http://murga-linux.com/puppy/viewtopic.php?t=72863
Back to the holiday cheer....
rerwin,
I am glad you understand all of that.
A few minutes to sink in.
Thank you very much for the fine tuning and your continued support.
We are in AWE.
I am glad you understand all of that.
A few minutes to sink in.
Thank you very much for the fine tuning and your continued support.
We are in AWE.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
"ask" in the /etc/shutdown_save_mode
Tnx rerwin, excellent work.rerwin wrote: - Allows user to choose to be asked whether to save during shutdown, by setting "ask" in the /etc/shutdown_save_mode file.
Sorry i haven't read through your codes but have one question regarding ask saving at shutdown.
How the user set the ask flag, /etc/shutdown_save_mode?
Isn't it easer to see the value of RAMSAVEINTERVAL set by the eventmanager?
My code in the pupsaveconfig(corresponding your update_save_layer_func):
It only ask when RAMSAVEINTERVAL=0, and no save without asking when RAMSAVEINTERVAL="-0".
Code: Select all
save_flash() {
[ -s /etc/eventmanager ] && source /etc/eventmanager
RAMSAVEINTERVAL=$(echo $RAMSAVEINTERVAL| tr -dc '0-9-')
[ "$RAMSAVEINTERVAL" != "" ] || RAMSAVEINTERVAL=30
NOSAVE=""
if [ $RAMSAVEINTERVAL -le 0 ]; then
if echo "$RAMSAVEINTERVAL" | grep -q '\-'; then
NOSAVE="yes"
else
dialog --timeout 60 --yes-label "SAVE" --no-label "NO SAVE" --yesno "Press ENTER key to save session...
Or, press TAB then ENTER to not save session...
Or, wait 60 seconds to shutdown without saving session..." 0 0 >/dev/console
[ $? -eq 0 ] || NOSAVE="yes"
fi
if [ "$NOSAVE" != "" ];then
rm -f /initrd${SAVE_LAYER}/etc/.XLOADED
echo -e "Session not saved." > /dev/console
return 1
fi
fi
echo -n "Saving session to $@... " >/dev/console
/usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw && echo "done." >/dev/console && return 0
echo -e "\\033[1;31mfailed.\\033[0;39m" > /dev/console
sleep 8
return 1
}
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
petget
Regarding the petget, i may be misunderstanding what you are going to, but i do not think your way is not a good solution.rerwin wrote: - Prevents conflict among installer, uninstaller and save snapper that could corrupt an installation.
My approach too does not solve the general issue on the install/uninstall pets but can be some help:
#Avoid was messing uo with save interval=0 under PUPMODE=13
http://www.murga-linux.com/puppy/viewtopic.php?t=73829
I think we need more investigation on this issue. One thought is to force running the snapmergepuppy after removing packages.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
Torrent file for Lupu 5.25-4
Unzip and open with Transmission or other torrent handler, and, please seed.
Unzip and open with Transmission or other torrent handler, and, please seed.
- Attachments
-
- Lupu-5.28-4.zip
- (41.95 KiB) Downloaded 531 times
shinobar,
Thanks for your feedback on patch-6.
I am open to implementing another way of specifying the choice for shutdown, but that is what I settled on for now, to get on with the rest of the fix. Maybe the option should be associated with snapmergepuppy, and a file, /etc/snapmergepuppy.conf.
EDIT: I found the code in script install.sh. I prefer to wait until Barry accepts that new code, before adding it to lupu, which is playdayz's call, anyway. But if there is a test case available that reveals a bug in lupu that would be fixed by it, we might consider adding it in the interest of "user-proofing."
Richard
Thanks for your feedback on patch-6.
RAMSAVEINTERVAL is intended to control only the automatic saving to flash drive. The prompting at shutdown is a separate issue. In response to playdayz desire for a "user-proof" puppy, but to avoid requiring user modification of a puppy script, I do not want to disrupt shutdown with a question that most users could not answer knowledgeably. A user comfortable with changing /etc/eventmanager for the automatic interval is also capable of editing /etc/shutdown_save_mode.shinobar wrote:How the user set the ask flag, /etc/shutdown_save_mode?
Isn't it easer to see the value of RAMSAVEINTERVAL set by the eventmanager?
I am open to implementing another way of specifying the choice for shutdown, but that is what I settled on for now, to get on with the rest of the fix. Maybe the option should be associated with snapmergepuppy, and a file, /etc/snapmergepuppy.conf.
Good point! I think it can/should be done in snapmergepuppy, in the "find" command for files, to exclude that file. It would also need a cleanup removal for existing pupsave files.shinobar wrote:Note that we need to delete the file /etc/.XLOADED (exists if the user made manual save by the 'save' button).
I am unfamiliar with that issue, but will examine your petget package to see if something should be ported to the patches.shinobar wrote:#Avoid was messing uo with save interval=0 under PUPMODE=13
EDIT: I found the code in script install.sh. I prefer to wait until Barry accepts that new code, before adding it to lupu, which is playdayz's call, anyway. But if there is a test case available that reveals a bug in lupu that would be fixed by it, we might consider adding it in the interest of "user-proofing."
Richard
Last edited by rerwin on Wed 21 Dec 2011, 17:54, edited 2 times in total.
oh I want to learn more about that one.shinobar wrote:
#Avoid was messing uo with save interval=0 under PUPMODE=13
I trust that I use it somewhere and do have set it to 0.
Too bad. I did not know it was problematic.
Shinobar if you have time or when you do feel for it.
I would not mind reading more about that problem.
Maybe it need it's own thread though.
I use Google Search on Puppy Forum
not an ideal solution though
not an ideal solution though
At last, another patch (6) for sound issues
rerwin
Firstly thanks for your enormous efforts & patches. Your research will no doubt be of benefit to all puppies not just 528.
With regard to your changes to rc.sysinit:
You may wish to consider expanding it as follows:
This has the benefit of also covering /dev/snd/by-path and also takes out all instances of mixer and sequencer eg mixer, mixer01 etc. Multiple instances of both sequencer and mixer will correctly exist where there are multiple devices.
Attached as image-1 below is a screenshot of a patched up fresh install of 004.
What concerns me, since I first saw the behaviour in my post about 003 on 17/12/11, is the time stamps. (Which I believe have nothing to do with your patches)
These nodes were all in fact created over 5 second period at 9:52 today – 21 Dec.
The bottom 7 however, which were created at the beginning of this period show a stamp 23 hrs earlier. The only explanation for this is that the HWCLOCK command (plus switches) was issued during this 5 second period.
Given that Alsa is a means of playing audio it has to keep accurate time and may be uniquely sensitive to these incorrect time stamps. Things could well go awry when DST turns on or off which could result in times of + 1 hour or + 25 hrs. Alsa could well disregard future times/dates and sound would then be lost.
Depending on the time-zone DST can cut in between MARCH to MAY inclusive and out between SEP to NOV inclusive.
In the attached file is a shot of wuxiandianzi’s 528 k3.1.0 which was based on the original 528 and it simply does not exhibit this behaviour. All of the date and time stamps over a 6 second period are correct.
In conclusion there has been some change to time stamping behaviour since the original 528. As it stands now it is definitely wrong and if what I suspect is correct a possible cause of sudden sound loss in Alsa. Perhaps a puppy time expert could investigate?
Firstly thanks for your enormous efforts & patches. Your research will no doubt be of benefit to all puppies not just 528.
With regard to your changes to rc.sysinit:
Code: Select all
rm -f /dev/ttyUSB* 2>/dev/null #101210 may have been left there if modem plugged in at shutdown.
rm -f /dev/mixer 2>/dev/null #110113 make sure removed, see test in /etc/init.d/10alsa.
rm -f /dev/snd/* #110304 after a reboot, some of these may be wrong.
Code: Select all
rm -f /dev/ttyUSB* 2>/dev/null #101210 may have been left there if modem plugged in at shutdown.
rm -f /dev/*mixer* 2>/dev/null #110113 make sure removed, see test in /etc/init.d/10alsa.
rm -f /dev/snd/* #110304 after a reboot, some of these may be wrong.
rm -f /dev/*adsp* 2>/dev/null
rm -f /dev/*audio* 2>/dev/null
rm -f /dev/*dsp* 2>/dev/null
rm -f /dev/*sequencer* 2>/dev/null
rm -f /dev/snd/*
rm -f /dev/snd/by-path/* #added for alsa v1.0.24
Attached as image-1 below is a screenshot of a patched up fresh install of 004.
What concerns me, since I first saw the behaviour in my post about 003 on 17/12/11, is the time stamps. (Which I believe have nothing to do with your patches)
These nodes were all in fact created over 5 second period at 9:52 today – 21 Dec.
The bottom 7 however, which were created at the beginning of this period show a stamp 23 hrs earlier. The only explanation for this is that the HWCLOCK command (plus switches) was issued during this 5 second period.
Given that Alsa is a means of playing audio it has to keep accurate time and may be uniquely sensitive to these incorrect time stamps. Things could well go awry when DST turns on or off which could result in times of + 1 hour or + 25 hrs. Alsa could well disregard future times/dates and sound would then be lost.
Depending on the time-zone DST can cut in between MARCH to MAY inclusive and out between SEP to NOV inclusive.
In the attached file is a shot of wuxiandianzi’s 528 k3.1.0 which was based on the original 528 and it simply does not exhibit this behaviour. All of the date and time stamps over a 6 second period are correct.
In conclusion there has been some change to time stamping behaviour since the original 528. As it stands now it is definitely wrong and if what I suspect is correct a possible cause of sudden sound loss in Alsa. Perhaps a puppy time expert could investigate?
- Attachments
-
- 528_k3.1.0.tar.gz
- (155.67 KiB) Downloaded 310 times
-
- image-1.png
- (81.65 KiB) Downloaded 691 times
Regards ETP
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]
others do have a better memory than I have
but have we not got recommendation to use
RTC and not local time due to this problem with
files suddenly getting wrong time stamp?
Sadly I don't remember who gave the advice and where
but I hope somebody else remember the details.
but have we not got recommendation to use
RTC and not local time due to this problem with
files suddenly getting wrong time stamp?
Sadly I don't remember who gave the advice and where
but I hope somebody else remember the details.
I use Google Search on Puppy Forum
not an ideal solution though
not an ideal solution though
messing up with save interval=0 under PUPMODE=13
See the report at last posts on the pupsaveconfig and no save:shinobar wrote:#Avoid was messing up with save interval=0 under PUPMODE=13
http://www.murga-linux.com/puppy/viewto ... &start=106
The problem occurs because the PPM saves the files not to the RAM but directly to the save layer for the flash install.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
@rerwin
1. I've applied/installed your patch-6, and all seems well.
But...
2. I'm no longer offered the option at shut-down = "Save the session? Yes/No".
So...
3. I'm about to change some code within file /etc/rc.d/rc.shutdown...
As per the instructions given in this post....
But I think You've probably included new code, and it may no longer be OK to make this change, so I thought I'd check back with you.
4. If I did proceed, I'd be changing this:
To this:
1. I've applied/installed your patch-6, and all seems well.
But...
2. I'm no longer offered the option at shut-down = "Save the session? Yes/No".
So...
3. I'm about to change some code within file /etc/rc.d/rc.shutdown...
As per the instructions given in this post....
But I think You've probably included new code, and it may no longer be OK to make this change, so I thought I'd check back with you.
4. If I did proceed, I'd be changing this:
Code: Select all
#the above are in unionfs at /.
update_save_layer_func $SAVEFILE \(${SAVEPART}\) #111208
;;
Code: Select all
#the above are in unionfs at /.
dialog --yesno "Save this session?" 0 0 >/dev/console
if [ $? -eq 0 ]; then
echo "Saving session to $SAVEFILE (${SAVEPART})..." >/dev/console
/usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw
fi
;;
luci-528.iso___lupu-528.004.iso.delta 13MB
luci-001.iso___lupu-528.004.iso.delta 35MB
luci-529.iso___lupu-528.004.iso.delta 30 MB
luci-001.iso___lupu-528.004.iso.delta 35MB
luci-529.iso___lupu-528.004.iso.delta 30 MB
Last edited by aarf on Thu 22 Dec 2011, 18:09, edited 2 times in total.
Sylvander,
Thanks for your feedback. I think I have addressed the shutdown-issue already.
shinobar,
Thanks for pointing me to that background on your install.sh modification. I believe the ability to shut down a flash drive session without saving goes beyond the official design of puppy. It seems to be used as an "undo" function, which could also be accomplished by uninstalling the installed package, then saving (first time, though). Other than package installation, choosing to not save seems OK to do. And keeping your alternative available for user installation seems appropriate. But there is another way to avoid saving....
As part of my mods to remasterpup, I provide a way to make a tailored CD/iso when the remasterer chooses to copy the entire /root and /etc directories to the new puppy. When that kind of CD is made, it by default skips saving on shutdown. To restore saving at shutdown, there is a flag file that (as I recall) would be deleted to override the default. The idea with that is to never save to anything. Again, that scenario is available to a knowledgeable/confident user ready to copy those directories for the remaster.
I am open to advice on improving the user experience with those "nerd-only" options, but am now keeping them "low profile."
EPC,
I have started a discussion with you by PM about the additional /dev removals at boot-up. Bottom line, though, is that Barry needs to be convinced they are necessary. So we need to make the case.
Richard
Thanks for your feedback. I think I have addressed the shutdown-issue already.
Apparently you missed this "fine print" in my patch announcement. It is already set up, so that you need only uncomment the line containing "#ask". I think that is safer than risking a typo while modifying internal puppy code. My other comment:rerwin wrote:- Allows user to choose to be asked whether to save during shutdown, by setting "ask" in the /etc/shutdown_save_mode file.
I think you qualify.rerwin wrote:In response to playdayz desire for a "user-proof" puppy, but to avoid requiring user modification of a puppy script, I do not want to disrupt shutdown with a question that most users could not answer knowledgeably. A user comfortable with changing /etc/eventmanager for the automatic interval is also capable of editing /etc/shutdown_save_mode.
shinobar,
Thanks for pointing me to that background on your install.sh modification. I believe the ability to shut down a flash drive session without saving goes beyond the official design of puppy. It seems to be used as an "undo" function, which could also be accomplished by uninstalling the installed package, then saving (first time, though). Other than package installation, choosing to not save seems OK to do. And keeping your alternative available for user installation seems appropriate. But there is another way to avoid saving....
As part of my mods to remasterpup, I provide a way to make a tailored CD/iso when the remasterer chooses to copy the entire /root and /etc directories to the new puppy. When that kind of CD is made, it by default skips saving on shutdown. To restore saving at shutdown, there is a flag file that (as I recall) would be deleted to override the default. The idea with that is to never save to anything. Again, that scenario is available to a knowledgeable/confident user ready to copy those directories for the remaster.
I am open to advice on improving the user experience with those "nerd-only" options, but am now keeping them "low profile."
EPC,
I have started a discussion with you by PM about the additional /dev removals at boot-up. Bottom line, though, is that Barry needs to be convinced they are necessary. So we need to make the case.
Richard
1. "you need only uncomment the line containing "#ask". I think that is safer than risking a typo while modifying internal puppy code"
(a) Oops, sorry about that.
What a great feature! How easy is that?
Mind you, I bet a total beginner wouldn't know it was there, or how to do it, unless told.
Obviously some of what you said went straight over my head.
I believe in something I call "Mind Blindness".
The eyes see...
The words are read...
But the full significance and meaning are simply NOT comprehended.
(b) Job now done.
Now to see if it does what I expect it should.
(a) Oops, sorry about that.
What a great feature! How easy is that?
Mind you, I bet a total beginner wouldn't know it was there, or how to do it, unless told.
Obviously some of what you said went straight over my head.
I believe in something I call "Mind Blindness".
The eyes see...
The words are read...
But the full significance and meaning are simply NOT comprehended.
(b) Job now done.
Now to see if it does what I expect it should.
rewin
1. "Package installations are prevented if an uninstallation has taken place in the same session before a save has been done"
Does this mean...
In relation to things happening within the same session:
(a) If an uninstallation has been completed, followed by clicking the "Save" icon on the desktop...
Then a package installation to follow would be prevented.
The user would need to reboot to a new session before attempting an installation.
OR...
(b) An attempt to install a package...
After an uninstallation...
But BEFORE that uninstallation has been saved...
Will be prevented.
The user would need to 1st save the uninstallation, and only then re-attempt the install.
2. "because the uninstallation may override the installation"
(a) I have no idea why an uninstallation would perhaps override an installation.
Hence, I fail to comprehend the significance.
3. "Uninstallations are prevented if a "save" or installation have been done"
(a) Shouldn't that say:
"Uninstallations are prevented if an installation and/or save have been done"...
This seems to me to be saying that whenever one or other or both [installation/save] have been completed [or even just started but failed to complete?]...
Then a subsequent uninstallation would be prevented.
4. "because the uninstall might corrupt an installation or fail to survive a reboot"
(a) Is this the reason you made the arrangement to prevent an uninstall under the conditions in 3 above?
So as to eliminate this risk; create certainty of success?
5. "The conflicting situations will require a reboot to trigger saving to flash drive between installations and uninstallations"
(a) OUCH! So only 1 install OR uninstall [not both, or multiples of both?] in any 1 session?
And yet, would not it be good enough to do a manual save DURING THE SESSION, and between the two [after the one, and before the other].
6. "Ideally, you should be able to uninstall, then save, then install, all in the same session. But this is not possible due to a problem with the package installer"
(a) A restatement, using other words, of the situation explained in 5 above.
This seems to answer my question in 5.
7. "It must be completely terminated in order for a "save" to be performed. But the installer/uninstaller does not terminate completely, leaving its main process executing, even though its dialog window is closed by the "Exit package manager" button"
(a) And this is the reason for the problem explained in both 5 & 6, as to why certain actions must be prevented, as explained above.
8. "To clarify how the conflict prevention works, it merely instructs the user to reboot if a conflict among packages is possible"
(a) Who decides [and WHEN], that a conflict is possible?
You [during coding?] or the user [at the point he is given the instruction to reboot]?
(b) Perhaps you might have said:
"Where I have previously determined that a conflict might arise when a certain package is being installed/uninstalled...
I have arranged that the code will instruct the user to reboot." [to avoid software corruption].
9. Have I [mis]understood?
Did I get close?
10. I'm now offered the choice "to save or not to save" at shutdown/reboot.
1. "Package installations are prevented if an uninstallation has taken place in the same session before a save has been done"
Does this mean...
In relation to things happening within the same session:
(a) If an uninstallation has been completed, followed by clicking the "Save" icon on the desktop...
Then a package installation to follow would be prevented.
The user would need to reboot to a new session before attempting an installation.
OR...
(b) An attempt to install a package...
After an uninstallation...
But BEFORE that uninstallation has been saved...
Will be prevented.
The user would need to 1st save the uninstallation, and only then re-attempt the install.
2. "because the uninstallation may override the installation"
(a) I have no idea why an uninstallation would perhaps override an installation.
Hence, I fail to comprehend the significance.
3. "Uninstallations are prevented if a "save" or installation have been done"
(a) Shouldn't that say:
"Uninstallations are prevented if an installation and/or save have been done"...
This seems to me to be saying that whenever one or other or both [installation/save] have been completed [or even just started but failed to complete?]...
Then a subsequent uninstallation would be prevented.
4. "because the uninstall might corrupt an installation or fail to survive a reboot"
(a) Is this the reason you made the arrangement to prevent an uninstall under the conditions in 3 above?
So as to eliminate this risk; create certainty of success?
5. "The conflicting situations will require a reboot to trigger saving to flash drive between installations and uninstallations"
(a) OUCH! So only 1 install OR uninstall [not both, or multiples of both?] in any 1 session?
And yet, would not it be good enough to do a manual save DURING THE SESSION, and between the two [after the one, and before the other].
6. "Ideally, you should be able to uninstall, then save, then install, all in the same session. But this is not possible due to a problem with the package installer"
(a) A restatement, using other words, of the situation explained in 5 above.
This seems to answer my question in 5.
7. "It must be completely terminated in order for a "save" to be performed. But the installer/uninstaller does not terminate completely, leaving its main process executing, even though its dialog window is closed by the "Exit package manager" button"
(a) And this is the reason for the problem explained in both 5 & 6, as to why certain actions must be prevented, as explained above.
8. "To clarify how the conflict prevention works, it merely instructs the user to reboot if a conflict among packages is possible"
(a) Who decides [and WHEN], that a conflict is possible?
You [during coding?] or the user [at the point he is given the instruction to reboot]?
(b) Perhaps you might have said:
"Where I have previously determined that a conflict might arise when a certain package is being installed/uninstalled...
I have arranged that the code will instruct the user to reboot." [to avoid software corruption].
9. Have I [mis]understood?
Did I get close?
10. I'm now offered the choice "to save or not to save" at shutdown/reboot.