Summary: | Dependencies review | ||
---|---|---|---|
Product: | SlackPack | Reporter: | Georgi D. Sotirov <gdsotirov> |
Component: | Core + Web site | Assignee: | Georgi D. Sotirov <gdsotirov> |
Status: | IN_PROGRESS --- | QA Contact: | Administrator <root> |
Severity: | enhancement | ||
Priority: | Very High (P1) | ||
Version: | cvs | ||
Target Milestone: | 0.5 | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://sotirov-bg.net/slackpack/ | ||
Whiteboard: | |||
My Bug ID: | My description: | ||
My date: | My choice: | ||
My selection: | --- | ||
Deadline: | 2019-10-31 |
Description
Georgi D. Sotirov
2007-03-13 21:47:08 EET
One problem with this approach is that not all packages that are requirements will be from SlackPack - there are official packages and Gnome SlackBuild packages. Either thy must be listed without links or the link should point to the remote repository. Will be dealt later. I though a lot about how to register the dependencies in the database. Initially I thought about an N:M table with the ids of the dependent packages, but this approach have the following problems: * not all dependencies are provided by SlackPack (i.e. won't be found); * some packages may have already been upgraded (i.e. would point users to old version); * representing the information as it's in the files with dependencies would give more flexibility in its interpretation and presentation later. So I proceed with a table that would register the contents of the files with dependencies. A point to consider in parsing dependency files is the possibility for alternatives in the format: pack1 >= 1.1 | pack2 >= 1.2 meaning pack1 or pack2 are required. The script for loading dependencies took over 3 hours, because the dependency files are extracted from the archives. real 185m9.622s user 126m14.653s sys 5m40.361s The script generated 75984 lines in new table package_deps with some duplicates: SELECT pack_id, dep_type, dep_name, dep_sign, dep_version, COUNT(*) cnt FROM package_deps GROUP BY pack_id, dep_type, dep_name, dep_sign, dep_version HAVING COUNT(*) > 1 ORDER BY cnt DESC, dep_name; This has to be investigated and fixed. Fixed problem with duplicated dependencies mentioned in previous command with commit https://github.com/gdsotirov/slackpack/commit/e330e4cf04e5f02369a29debb0e9bc728bf1e660. The second loading of dependencies for the packages with duplicates took about 2.5 hours: real 150m23.877s user 95m18.808s sys 5m10.184s There are still some duplications identified by the following query: SELECT pack_id, dep_type, dep_name, COUNT(*) cnt FROM package_deps GROUP BY pack_id, dep_type, dep_name HAVING COUNT(*) > 1 ORDER BY pack_id, dep_type, dep_name; which should be due to duplication in the dependency files themselves, but to be checked. The dependencies loaded into the database are now displayed in three sections - Requires, Suggests and Conflicts on package details page (see commits https://github.com/gdsotirov/slackpack/commit/60f62742fee4ab966b202e82d9a5832dbaef1c26 and https://github.com/gdsotirov/slackpack/commit/5dae823071b75d871626a2e3afaed3491efe984a). This visualization should be improved. |
bug/show-multiple.html.tmpl processed
on May 14, 2024 at 11:23:20.
(provided by the Example extension).