#844 Make the text about "application independence" generally applicable
Merged 4 months ago by ignatenkobrain. Opened 6 months ago by zbyszek.
zbyszek/packaging-committee package-independence  into  master

@@ -72,21 +72,25 @@ 

  application that depends on a library or service should not automatically

  pull in other applications associated with that library or service.

  

- === Application Independence

+ == Package Independence

+ 

+ Packages SHOULD be installable independently whenever this is technically feasible,

+ but they MUST specify dependencies of correct type on other packages if necessary,

+ see <<Dependency types>> below.

+ 

+ Desktop applications MUST NOT depend on other desktop applications unless strictly required.

+ In particular, packages that contain a visible `.desktop` file (a `.desktop` file that does not contain the line

+ `+NoDisplay=true+`) SHOULD NOT have a `Requires`, `Recommends`, or `Supplements`

+ on any other package containing a visible desktop file, directly or indirectly.

  

- Applications SHOULD be installable independently whenever this is technically feasible.

- Packages that contain a visible .desktop file (a .desktop file that does not contain the line

- `+NoDisplay=true+`) SHOULD NOT have a Requires, Recommends, or Supplements

- on any other package containing a visible desktop file, directly or indirectly, unless the

- dependency is required for technical reasons or truly makes sense to have.

  For example, it would be reasonable for a video game level editor to

  require the associated video game in order to function, or for an application's plugin to

  require the associated application. But it would not be reasonable for an application that happens

- to use a database library to depend on a database management application associated

+ to use a database library to depend on a database management suite associated

  with that library, or for an application that happens to use a particular programming language

  to depend on management tools associated with that programming language.

  

- If a source package provides multiple desktop applications, those

+ If a source package provides multiple graphical applications, those

  applications SHOULD be packaged in separate subpackages when feasible.

  

  == Spec Files

@@ -335,6 +339,16 @@ 

  

  A versioned dependency on a package with a defined Epoch MUST be included in that dependency. Otherwise the dependency will not function as expected.

  

+ === Dependency types

+ 

+ `Requires` MUST be used if the dependency is required for the software to function correctly.

+ 

+ If the package functions correctly but in diminished capacity, then

+ `Recommends` or `Suggests` SHOULD be used.

+ If the functionality should be available by default for users, `Recommends` SHOULD be used, and `Suggests` otherwise.

+ Alternatively, the reverse dependencies `Supplements` or `Enhances` may be used in the other package.

+ See xref:WeakDependencies.adoc[Packaging:WeakDependencies] for guidelines on using those dependency types.

+ 

  === Architecture-specific Dependencies

  

  A dependency is made arch-specific by appending the macro `+%{?_isa}+` to the package name. For example:

@@ -362,10 +376,6 @@ 

  

  `+Requires: glib-devel%{?_isa} libXi-devel%{?_isa} libXext-devel%{?_isa} libX11-devel%{?_isa}+`

  

- === Weak dependencies

- 

- Weak dependencies (`+Recommends:+`, `+Suggests:+`, `+Supplements:+` and `+Enhances:+`) MAY be used to specify relationships between packages which are less strict than mandatory requirements. Please see xref:WeakDependencies.adoc[Packaging:WeakDependencies] for guidelines on using these tags.

- 

  === Rich/Boolean dependencies

  

  Packages MAY make full use of the http://rpm.org/user_doc/boolean_dependencies.html[rich (or Boolean) dependency feature] supported in RPM.

The existing text had a very narrow scope: packages that contain a
.desktop file that does not have the line +NoDisplay=true+. But the same
rule applies to pretty much everything.

Let's remove the part about "NoDisplay=" and change "application" to
"package" to generalize this.

This partially answers the question about "modularity" (in the sense
of package independence) raised in https://pagure.io/fesco/issue/2040.

This definitely needs an issue open for discussion as I think it's not an insignificant change.

I guess it is understood that this change will not have it's full effect in a short time.
Aim, in my perception, is to minimize dependencies so that software can be chosen more freely.

Certain software ends up on systems where it cannot be used, e.g. bolt on a thunderbolt-less system, iio-sensors-proxy on system without these sensors, wifi firmware on systems without wifi.
Also certain software might not be desirable but cannot really be removed (e.g. gnome-online-accounts).
There might be more situations where a choice cannot be satisfied by the packaging system.

This means that packages SHOULD NOT have a Requires, Recommends, or Supplements on any other package, unless the dependency is required for technical reasons or truly makes sense to have.

I mean, this should really be the case anyway. I don't see why packages should have dependencies when it's not required for technical reasons or truly makes sense.

However the explicit rule about desktop files was actually there for a reason. Users get confused when they install coolapp_written_in_java (or libreoffice) and suddenly they see OpenJDK 1.8.0 Policy Tool 1.8.0.191.b12-11.fc29.x86_64 in their menus.

I mean, this should really be the case anyway

Well, yes, that's what seasoned packagers expect and treat as obvious. But the rule wasn't actually stated anywhere. A new packager or user might reasonably wonder whether a dependency on a related-and-useful package should be added or not. In Fedora we say "no", but a different distro which values ease-of-use over a little bit of disk space might answer "yes". How to decide this doesn't have a strict technological basis, and we need to draw the rule somewhere. I think that explicitly stating the rule is useful.

However the explicit rule about desktop files was actually there for a reason. Users get confused when they install coolapp_written_in_java (or libreoffice) and suddenly they see OpenJDK 1.8.0 Policy Tool 1.8.0.191.b12-11.fc29.x86_64 in their menus.

Ack. The proposed update is a superset of the old rule, so the graphical app case is still handled. I can add back the mention of the graphical app case explicitly if you think it's important.

I think it's explicitly important. But let's wait for the opinion of others before you change things, so you don't need to change back and forth.

I would like to have guideline which says something like:
If it's mandatory dependency (aka app won't work without this dependency), the you MUST use Requires
If it's optional dependency (aka app will work without this dependency), then you MUST use Recommends or Suggests
In case this functionality should be available by default for users, you MUST use Recommends
Otherwise, you MUST use Suggests
* Desktop applications should not depend on other desktop applications unless strictly required.

Shouldn't there be a well formulated text about what effort the developer must invest to make their software as independent as we like it to be?
Our could we cover this case by stating that at any time the user should be able to remove the software without hampering certain core functionality?

rebased onto 312b09b19ea44e83ead864bc5cd8eccb1513c92c

6 months ago

rebased onto 78a2d6d

4 months ago

Pull-Request has been merged by ignatenkobrain

4 months ago
Metadata