> I really do like this. There are only two issues I have with it: > > 1. This seems to mandate that all packages must be named by their > import path. My golang package (snapd) is not, intentionally so. I > don't want to change this. > > 2. Mandating a forge is going to be tricky for self-hosted stuff, or > people who release Go code as tarballs (it's rare, but it happens). > How do you deal with that? By not using the macros for packages not fitting the model? I think this is very helpful especially when it's the common practice, and I certainly won't blame anyone doing proper releases and not just a git tag with github releases notes ;) Regarding naming, I think python packages must be prefixed with python[23]- and can Provides: the upstream project name. On the other hand we have packages like docker that are clearly named after upstream's name, so I don't think that would be a problem for snapd. (and maybe an exception needs to be granted?) Dridi _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
