Hi, You are correct that the goal of this project is produce software, not deploy or provide a service. As such, the project has nothing to do with a centralized database keeping data for others. This would imply a service and introduces a number of other problems, which are not part of this project. I think it would be easier to have the software based on abstractions like "get_list_of_packages", "get_package_details" and "get_package_source", which can be implemented for various distributions. By far the easiest way to implement these are by using the package managers -- that's what they were implemented for. Trying to reverse engineer all of them to find out how they work and develop software to use the underlying data is much more work, resulting in much more fragile code. I, personally, know the details of Debian packages, but I am blissfully ignorant when it comes to other distributions. I do not rule out this idea, but be prepared to spend a LOT of time documenting and implementing lots of package manager functionality for something that is a secondary task of the project. Because you will obviously not simply _use_ the "DB files" as you write; you would have to write code to find out which these are and fetch them, etc. I'd hate to see student fail their project because they got too much to do on a side task. On Mon, Apr 5, 2021, at 14:56, Vividh Mariya wrote: > Hello ! > I had a doubt regarding the PackageInfo WebApp project. You've > mentioned about getting a pointer to the exact sources of a package > using SWHID's in this mailing list before. Also, as far as I could > tell, this project is supposed to be something that users can easily > install on their own systems, or self-host on a vps somewhere, instead > of providing a central service where users can go to. > > 1) Most mainstream distros do have some packages already added to the > SWHID archive, but there are a lot of packages that are missing. Since > every user of this software will be maintaining and updating their own > copy of the database, will they be pulling down sources of every > package, calculating the SWHID, and requesting to put it on the > archive (if not already present), or should we have a central database > where users can query to get the SWHID (if already present) ? > > 2) Regarding getting the package metadata of all distros, I had made a > test script using that spins of docker containers of Ubuntu, Fedora > and Arch Linux, uses the respective package managers, and get the > package information. But while listing entire package lists, very > little information is extracted. To get more detailed stuff like the > link to the .deb / .rpm file, download size, md5 hash etc. we have to > query it on a per package basis. > Would it be viable ( and maybe faster ) to not use the package > managers, instead get the DB files ( like > http://mirror.rise.ph/archlinux/core/os/x86_64/core.db ) from a mirror > and parse them directly ? > > ---- > Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και > συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του > Google Summer of Code - A discussion list for student developers and > mentors of Google Summer of Code projects., > https://lists.ellak.gr/gsoc-developers/listinfo.html > Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. > ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr > <mailto:gsoc-developers%2Bunsubscribe%40ellak.gr>>. > -- -- zvr -
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.