-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency handling by user. #432
base: main
Are you sure you want to change the base?
Conversation
- Better handling terminal
- Change name of this routine to get_record - Enchance readability
2. Initialize transaction_problems.problems2 and zypper backend's priv structure 3. Remove break of loop in zypper_perform_execution, so we test if user begins another transaction_problems 4. Checking if size of list is not zero, so we omit some code 5. Syntax cleanup 5. Sending errors to default error file description instead of standard output 6. Fill some structure before caching it
I modify code, so it's now more behaves more correctly. I correct cache behavior, so user don't be forced to handle dependency twice and there's no wrong assumption cache file associate to current change. We cache user responses, so now my code behaves much better. I still have many things to do. For example I must add code to remove cache files on exit and split UI code to different process, so we will have multiuser support and we could reduces privileges of UI by passing restrictions to UI process' rights. |
dependency handling - Remove dependency of libdbus and libBonsoleClient from zypp backend and moved it to dependency helper - Added dependency helper directory - Added helpers directory to project
tool to solving dependency
- Do not free job data if backend didn't comply task - Add communication between packagekit zypp backend and dependency solving helper - Change semantics of communication protocol (see above), so we send or not null bytes pointing string end - Change get_record (in helper) routine, so we work well with pipes - Change code responsible for displaying message, so we avoid many bugs
- Added method to check if transaction is in dependency solving state and invocation of this method - Make page of dependency solving look better
- Segfault remove
README
Outdated
@@ -5,3 +5,8 @@ PackageKit is a DBUS abstraction layer that allows the session user to manage | |||
packages in a secure way using a cross-distro, cross-architecture API. | |||
|
|||
For more information, please see http://www.packagekit.org | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was probably intended to be for your personal fork, not the upstream README.
- Remove unnecessary debug information - Added support for more exceptions - Push problems description, so it could been cached - Applying resolution more ofter
…mallBugHuntingAndImprovements1
…mallBugHuntingAndImprovements1
- Repair bugs related to problems with dependency interactive solver's communication - Better initialize job related structure
- Add field to backend_job_private (zypp) indicating backend initialize communication channel with program to dependency solving - Add some sanity check - Add routing to apply resolution from cache (it's different than apply resolution from interactive solving, but in future we need to combine both routines) - Properly init msg_proc_helper in job-related structure (introducing previously indicated field is related to this change) - Remove unnecessary comments - Add invocation of apply_resolution_from_cache
- Remove cache file
program) in zypp backend
One thing that should actually be mentioned: PackageKit has a policy of never asking questions once a transaction is triggered (previously also known as "hughsie's law"), and we go through great lengths to prevent that. The only exception is probably certain high-priority Debconf questions getting passed through on Debian, but everything else adheres to that rule, and it is also an essential requirement for offline updates. |
As for the Ci failures: You are building the |
@ximion I saw PackageKit have function to test transaction is interactive. I suppose I must check value of this flag. Bonsole's source are on source forge. No packages yet - only sources. Bonsole is a project, which are assemblies by client library and web browser with UI and etc. to support Bonsole apps. Bonsole means browser console, but it's support html form, buttons, etc. When UI isn't accessible, client library will load console backend and translates Bonsole's markup language to console tui app. Bonsole uses special markup language and xslt to translate it output for console/web browser backend (depending which backend are loaded). About package manager. There could be many cases like updating some software could causing dependency problem. I often got problem with updating software in OpenSUSE Tumbleweed. Situation could be similar: package A request older version of libA, but package manager tries to update package B, which needs newer version of libA. When using of tray applet, in many cases I was unable to update my system. |
About the CI system. I learn meson/ninja currently, but I thought helper was disabled on my system, I added this line: |
@ximion: |
@ximion: |
- Now case cancel installation of package via dependency problem solutioin worked - change other patch (uninstall/upgrade/etc.)
- Not including packages twice (once dependency solution applied)
- Remove bugs in dependency formating tool, causing bad number of checkbox generated and bug causes html code are part of checkbox - Remove bug causing messages do not appear - Add Processing message
- Remove bugs in dependency formating tool, causing bad number of checkbox generated and bug causes html code are part of checkbox - Remove bug causing messages do not appear - Add Processing message - Code cleanup - Dependency handling code refactorization - Added message in case, when communication with helper is broken - remove dead code - show message, when nothing to do - partially added code to show message, when some errors ocours on depdendency handling process - reverted change with adding task to do if called from dependnecy-handling-code
…andling/PrettyOutput
Include code reposnsible for old path of handling case, when tool asks for non-interactive dependency handling
logical arithmetic problems
- Repair some backend messages and makes clarifiration - Move dependency solver error message to new routine and call it only if dependency_solver_helper fails
- Repair bug made gnome-software think package is installed properly, but it not
This bug was caused tmpDir object was not persist between routine, which checks dependency and try to install package
It is curremtly used only by zypp backend
- Handle error flag in install local files - Both changes are related only to zypp backend
Some things worked at last, but you must install servicesUI (daemonUI) and Bonsole. There's still many things to do. For example, I prefer to find a way do not block packagekit daemon. You probably think rendering UI by daemon at all is bad idea, but it have many advantages. I am not sure it at all less secure. Take in mind we talking about dependency handling. What if discover or some other software ran by user take decision about how solve dependencies instead of user? It also allows to repair older software and delivering new possibilities to it. It could be better if I don't block packagekit, so I will search a way to achieve this. Another, but related thing is that currently my solution is only for single user. Bonsole library could be initialized only once, so I must add support for fork child process, which will use Bonsole library and communicate with Packagekit. I imagine, that If I do this, I could replace current code with non-blocking one. For example remember pipe and pid of child in job structure, do not send response just after zypp_perform_execution ends, but when task is really done. Cache code must be better - packagekit don't clean cache related to selection (it create cache file to user selection, so if user handle dependency it won't be asked second time for handling after password type). Cache also made easier to do non-blocking packagekit, because we could perform lock zypper, release lock when dependency error and user interaction is needed, render UI, wait for user interaction, lock package manager, perform the same test, release lock, render UI, ..., perform operation. I also look how to modify servicesUI to made possible non-blocking behavior. For example render UI by service UI and launch packagekit if user send form. There's many possible solutions.
I must admit I'm beginner C programmer. C++ is not my best skill. I'm waiting for any suggestions. That's not final merge request, but request for code review. I known my code look like a rubbish.