On Mon, 2019-11-04 at 14:20 -0500, Matthew Miller wrote: > It would be useful for that contributor to be able to say "I build > these > packages so I can ship the thing I'm invested in, but... user and > other > contributors, beware". > Now, solving that isn't in the requirements modularity, but it *is* > something that'd be nice to address, so if modularity happens to, > cool. The post that Stephen wrote seems to say that solving this is in the requirements of modularity. Specifically this section: > Defining the public API > > Similarly, there are times when an application the packager cares > about depends on another package that is required at runtime, but > sufficiently complex that the packager would not want to maintain it > for general use. (For example, an application that links to a > complicated library but only uses a few functions.) > > In this case, we want there to be a standard mechanism for the > packager to be able to indicate that some of the output artifacts are > not supported for use outside this module. If they are needed by > others, they should package it themselves and/or help maintain it in > a shared place. > > Requirement: Packagers must be able to encode whether their output > artifacts are intended for use by other projects or if they are > effectively private to the alternative version. Packagers must also > have a way of finding this information out so they understand what > they can and cannot rely on as a dependency. Is it a requirement? Or did you mean something else?
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
