Wikidata:Property proposal/software package
software package[edit]
Originally proposed at Wikidata:Property proposal/Creative work
| Description | package management system used to publish the software |
|---|---|
| Data type | Item |
| Domain | software (Q7397)   |
| Allowed values | subclass of (P279) package management system (Q891055) |
| Example | Mozilla Firefox (Q698) → dpkg (Q305892) or Twisted (Q969382) → pip (Q6541095) |
| Planned use | add the software package property to existing FLOSS software |
- Motivation
There should be a new property named software package to convey the information that a package exists for the software and is suitable for a given package management system (Q891055).
What does it mean for the end user? If a popular software is packaged for dpkg (Q305892), there is a good chance it is available in the repository of Ubuntu or Debian GNU/Linux. The qualifiers can be used to be more precise about the context in which the package has been tested to work (for instance if the Debian GNU/Linux jessie operating system is associated with a reference URL to the corresponding package page).
What does it mean for the developer? If the software has been packaged for dpkg (Q305892) and is available on Ubuntu Trusty, it may not be installable on Debian GNU/Linux Jessie. Similarly, if a python package has a pip (Q6541095) package, it may be installable with python2 but not with python3. However, the developer can use the existing package and adapt it to the desired context instead of starting from scratch.
Who authored the package? A deb package installable on Debian GNU/Linux is often created by a person who is a Debian Developer and does not otherwise participate in the development of the software itself. A python package installable with pip (Q6541095) is often created by someone participating in the development of the software. The developer of the software is not necessarily the same as the packager.
Is packaging part of the software? The sources of a python package installable with pip (Q6541095) often contain all the information and software required to build the package. It is good practice for a deb package to be maintained in a repository separated from the software itself, although it sometime is part of the software itself (native packages). In theory it is best to separate the packaging lifecycle from the development lifecycle but the reality is different, depending on the packaging system and the distribution environment.
How is it different from platform (P400) or operating system (P306)? The platform (P400) for which a software has been developed was designed to be used to designate the underlying hardware architecture such as in Mozilla Firefox (Q698) where it is stated to be available for the PlayStation 3, Xbox, x86, x86_64 and ARM platform (P400) and the talk page examples and discussion also go in that direction. The actual usage of platform (P400) is significantly different but does not match the way the software is packaged. The operating system (P306) states that a given software is expected to be run and compile but does not imply a software package is available. It may be the case that a software is available in source form, expected to compile on Debian GNU/Linux squeeze, but has no Debian Package available. If someone is willing to run the same software on Windows, some kind of porting will be required.
- Discussion
Support of course I support my own proposal :-) Dachary (talk) 08:31, 24 July 2016 (UTC)
Question is this stable? My first thought is that this is information that is probably not really within Wikidata's scope, as what packages are available can vary by operating system, software version and repository. How official and/or available does a package have to be before it gets included here? Is any of this information available in reliable sources? Thryduulf (talk) 10:58, 19 July 2016 (UTC)
Answer it is at least as stable as the operating system (P306) and sometime even more: it is not uncommon for a project to distribute package files that can be installed on multiple operating systems that share the same packaging system (for instance most python packages can be installed on any Operating System as long as it runs a version of Python (Q28865)). It also is more durable in the sense that a source package contains precise build instructions for the software. The unpackaged source archive should also contain compilation instructions but they are sometime incomplete (because they are not as automated as they are in a source package. Dachary (talk) 15:15, 19 July 2016 (UTC)- @Dachary: I'll
Oppose for now especially because of the example. Gimp for example is included into debian, so it's naturally using deb files. Are you limited to the editor of the software (the gimp team) or do you allow any distro ? author TomT0m / talk page 18:38, 23 July 2016 (UTC)
- @TomT0m: You are correct, a given Operating System has a preferred packaging system :-) But it's never exclusive. For instance thousands of python modules are installable on Debian GNU/Linux with pip (Q6541095) and do not have deb packages. This property should not be limited to the editor of the software, nor should it be limited to a given distribution or Operating System. I hope that addresses your concerns. Dachary (talk) 08:30, 24 July 2016 (UTC)
- @Dachary: Not really, it seems either too much or not enough, at least not mature. Why the distribution software and not the package format for example ? More important : it is often not enough to know the package format to know if you can install it on your computer as it's often linked to the version / distribution (Ubuntu whatever, debian sid in 2006, Windows 2000 ... ) I don't think this is really useful in this state. Needs more thinking. author TomT0m / talk page 08:36, 24 July 2016 (UTC)
- I mean, more thinking and probably a consistent and more complete model with several properties working together. author TomT0m / talk page 08:37, 24 July 2016 (UTC)
- @TomT0m: I reworked the description above to address your concerns. Did I miss anything ? Dachary (talk) 11:06, 24 July 2016 (UTC)
- Actually not really. It seems to be at least a contradiction on your description of platform (P400)
usage and the description stated for this property. I think the discution should occur on WikiProject Informatics. I thinkwe should try to build a complete and consistent model for software and software distribution, with a set of real world example, then we should propose the needed properties and qualifier. And what we want to be able to model, and what we don't really want to be able to model : there is a lot of information in your description, and at first glance I'm not sure that we should not have more explicit ways of doing things : why should not have a definite way to model that a package buildingscript is included into a free sofware package ? What about mobile apps and so on ? author TomT0m / talk page 12:24, 24 July 2016 (UTC)
- I updated the description to clarify that P400 intended and actual usage is not redundant with the proposed property. Dachary (talk) 13:51, 24 July 2016 (UTC)
- I think there is value in having a property that simply states the fact that there exists a package for a given software. It is a simple a useful fact regarding the software, regardless of other considerations. You are right, a discussion on the broader subject of modeling software and software distribution is outside of the scope of this discussion. If you initiate it, I'd be happy to participate. Dachary (talk) 13:56, 24 July 2016 (UTC)
- Mmm the problem whatever the interpretation of the property is and would not have been redundancy. There is ports of apt or dpkgs for a lot of OSes, and platform like Java have a standard package distribution format with jar. This seems even almost totally orthogonal and your change of description does not clarify anything imho. As you may know, a software platform and a hardware one can be different only in apparences as there is emulators that can implement an intially hardware platform and conversely hardware can implement software one (Lisp machine (Q1653376)
) so the distinction is not that easily drawn. I'll say a platform is a combination of hardware and software a software can run on, like Windows/x86 or any equivalent emulator, or wine or java. author TomT0m / talk page 14:49, 24 July 2016 (UTC)
- Mmm the problem whatever the interpretation of the property is and would not have been redundancy. There is ports of apt or dpkgs for a lot of OSes, and platform like Java have a standard package distribution format with jar. This seems even almost totally orthogonal and your change of description does not clarify anything imho. As you may know, a software platform and a hardware one can be different only in apparences as there is emulators that can implement an intially hardware platform and conversely hardware can implement software one (Lisp machine (Q1653376)
- Actually not really. It seems to be at least a contradiction on your description of platform (P400)
- @TomT0m: I reworked the description above to address your concerns. Did I miss anything ? Dachary (talk) 11:06, 24 July 2016 (UTC)
- @TomT0m: You are correct, a given Operating System has a preferred packaging system :-) But it's never exclusive. For instance thousands of python modules are installable on Debian GNU/Linux with pip (Q6541095) and do not have deb packages. This property should not be limited to the editor of the software, nor should it be limited to a given distribution or Operating System. I hope that addresses your concerns. Dachary (talk) 08:30, 24 July 2016 (UTC)
- Support a Wikibooks template publishes this property since 2008. JackPotte (talk) 17:02, 24 July 2016 (UTC)
- What that exactly means Firefox uses dpkg? Generally, it's distro/OS specific, isn't it? --Dereckson (talk) 19:54, 3 August 2016 (UTC) I wonder if that wouldn't be a good idea to use this as a qualifier for OS. (Firefox is available on Linux, qualifier package system: dpkg)
- If dpkg is used to package Firefox it means there exists a package description compliant with dpkg for Firefox. Given that it is one of the most complex packaging system, it means that a developer can use it as a base. And for the user point of view it means that if an Operating System is based on dpkg (which is the case of both Debian GNU/Linux and Ubuntu) there is a good chance that a package for Firefox exists and is ready to use. A packaging system is not distro specific: npm and pip are notoriously distro independant. I agree with you, it could be used as a qualifier for a given Operating System: for instance knowning that python-openstack is available as a dpkg package as well as a pip package could be useful to some people. The Operating System could also be used as a qualifier for a given software: some python packages need to be compiled, even when installed via pip in which case it would be meaningfull to state that such a software can be installed with pip, with qualifiers stating for which Operating Systems it has been ported. Dachary (talk) 20:22, 3 August 2016 (UTC)
- Support Useful because no other propriety or qualifier can be used to convey this information. Johanricher (talk) 08:26, 4 August 2016 (UTC)
- Support idem Johanricher. — Metamorforme42 (talk) 15:08, 5 August 2016 (UTC)
Done @Dachary, Thryduulf, TomT0m, JackPotte, Dereckson, Johanricher: --Tobias1984 (talk) 07:12, 6 August 2016 (UTC)