I meant that the alternative approach (i.e. the link to the compressed sources) would be only used for those packages that have not yet been archived via SWHID; I should have expressed it more clearly, apologies for that. In any case I totally agree that uploading those packages to the SWH archive, and thus contributing to package archiving regardless of the particular project, is a better approach. Looking through the SWH API it is required to provide a link to a Subversion, Mercurial or Git repository publicly accessible, so should we temporarily create online public repositories to host the packages' sources in some popular hub (Github, Bitbucket, GitLab etc), until the archive process is completed ? As for the periodic update of the database in order to include newer versions and new packages, would it be ok to use the Advanced Python Scheduler <https://apscheduler.readthedocs.io/en/stable/index.html> which can be combined with the popular python web frameworks ? Furthermore, regarding the package collection from multiple different linux distributions I was considering using docker images of each distribution that will run the necessary corresponding package manager's commands. What do you think about that ? Lastly, I would like to ask you if there is a need to include UI wireframes in the proposal. Warmly, Giannis Στις Πέμ, 25 Μαρ 2021 στις 1:27 π.μ., ο/η Alexios Zavras <zvr+eellak [ at ] zvr [ dot ] gr> έγραψε: > Great to hear about the advances. > > The SWHIDs are the most stable constant identifier that can be used, > so let's use these. Any other link is not guaranteed for long-term usage. > > In general: if a specific package is not present in the SWH archive,... > we can simply upload it -- and make the archive better. > > FYI, if you are interested in the current state, all Debian packages > are already in the archive and most of the Ubuntu ones are not (yet). > > On Thu, Mar 25, 2021, at 00:11, John Pap wrote: > > Thanks a lot for your helpful guidance! > > > > Regarding the pointer to sources matter, I managed to fetch a package's > > source code in an Ubuntu distribution using the apt-get source command > > to locally fetch it and then generate its SWHID using the corresponding > > cli tool. It's indeed an elegant way to refer to code archives that I > > was not aware of. > > However, I was wondering whether it's guaranteed that all packages' > > sources have been archived via SWHIDs. > > If the latter is the case, I was considering alternatively providing a > > link to the compressed (in a tar.xz format) packages' sources in the > > Ubuntu archive, so that the user can download and review them locally. > > > > I'm looking forward to your feedback! > > Thank you in advance for your time, > > Giannis > > > > > > Στις Τρί, 23 Μαρ 2021 στις 1:56 μ.μ., ο/η Alexios Zavras > > <zvr+eellak [ at ] zvr [ dot ] gr <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr>> έγραψε: > > > Well done on the collection of data! > > > > > > As I've written before. some of the ones you mention > > > are crucial (e.g., name, version), some might be of interest > > > (e.g., size, license), some are very difficult to handl > > > (e.g. dependencies), and some are very distribution-specific. > > > It's perfectly fine to start with a small set. > > > > > > One that definitely has to appear in our system > > > is a pointer to the exact sources for each package. > > > These can be generated by getting the source of the package > > > and producing the SWHID for it. > > > > > > > > > Oh, and to your last question, yes, apt(8) should not be > > > the only supported way to get the information. > > > Depending on the distribution, other equivalent > > > commands will be used. Keep in mind that even > > > older Debian systems do not have the "apt" command. > > > > > > On Mon, Mar 22, 2021, at 23:49, John Pap wrote: > > > > Hello Sir, thanks for your clear response ! > > > > > > > > I was considering the same approach regarding the database > > > > manipulation, i.e. that there will be append only operations. > > > > I have also managed to retrieve various characteristics for all > > > > available packages in an Ubuntu distribution, using the apt command; > > > > namely the package name, version, size, category, dependencies, > > > > homepage site, description, maintainer, architecture type, bugs > site, > > > > among others that are too technical and should better be omitted in > my > > > > honest opinion. Βut of course I would like to hear your point of > view > > > > as well. > > > > Furthermore, I would like to ask you if there is a need to include > > > > packages' info for non Debian based linux distributions that do not > > > > support the apt command. > > > > > > > > Best Regards, > > > > Giannis > > > > > > > > Στις Κυρ, 21 Μαρ 2021 στις 10:50 μ.μ., ο/η Alexios Zavras > > > > <zvr+eellak [ at ] zvr [ dot ] gr <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr> <mailto: > zvr%2Beellak [ at ] zvr [ dot ] gr <mailto:zvr%252Beellak [ at ] zvr [ dot ] gr>>> έγραψε: > > > > > Hi Ioannis, thanks for your interest in the project. > > > > > > > > > > You are absolutely correct: the info in the database > > > > > will be collected independently of the web querying front-end. > > > > > (whether there will be a RESTful API remains to be determined). > > > > > > > > > > You are also correct that there should be a mechanism > > > > > for updating the database with new information. > > > > > Given the nature of the data, it is probable that data > > > > > will never be deleted, only added. > > > > > So it would make sense to have the updating process > > > > > add the data that is not already present in the database, > > > > > rather than generating everything from scratch again. > > > > > > > > > > On Sat, Mar 20, 2021, at 23:52, John Pap wrote: > > > > > > Greetings Everyone, > > > > > > > > > > > > My name is Papadopoulos Ioannis, I have graduated from the > National > > > > > > University of Athens and I'm currently pursuing my MSc in Web > > > > > > Engineering. I have previously engaged with open source projects > and > > > > > > I'm highly interested in contributing to the particular project > idea. > > > > > > > > > > > > Having carefully read the related threads, and please do correct > me if > > > > > > I'm wrong, I have concluded that the database containing all the > > > > > > packages' info will be populated once and then the frontend will > > > > > > retrieve the appropriate data from the backend (responsible for > > > > > > querying the database) via a RESTful API. > > > > > > However, I was wondering whether we would possibly want to > periodically > > > > > > repopulate the database, in order to include newer versions and > new > > > > > > packages. > > > > > > > > > > > > With Appreciation, > > > > > > Papadopoulos Ioannis > > > > > > > > > > > > ---- > > > > > > Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και > > > > > > συζητήσεων που απευθύνεται σε φοιτητές 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 [ at ] ellak [ dot ] gr> <mailto: > gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr <mailto: > gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr>> > > > > > > <mailto:gsoc-developers%2Bunsubscribe%40ellak.gr <mailto: > gsoc-developers%252Bunsubscribe%2540ellak.gr> <mailto: > gsoc-developers%252Bunsubscribe%2540ellak.gr <mailto: > gsoc-developers%25252Bunsubscribe%252540ellak.gr>>>>. > > > > > > > > > > > > > > > > -- > > > > > -- zvr - > > > > > > -- > > > -- zvr - > > -- > -- 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>.