On Fri, 2015-09-11 at 11:51 -0400, Bill Nottingham wrote: > 3) Does "package all the things" really make sense, anyway? > > What is the gain from 'conform Chromium to our package regulations' > gain us? > A few people who won't just install Chrome for F/OSS reasons? If > that's the > goal, we should be clear that that's the tiny set of users we're > targeting. > Maybe it makes sense if we're moving to Chromium as our main deployed > browser ala the Endless folks. But if we're not, banging Chromium > into our > guidelines in a way that Google themselves doesn't particularly care > about > or support doesn't gain us much. Hope I'm not repeating myself, but I'd just like to say I absolutely 100% agree with this, and that's why I was suggesting any review of the bundling rules should be part of a wider conversation of what our story on 'how you should run software on Fedora' actually is - which certainly involves topics like the Rings and possible 'official' Fedora software delivery methods other than RPMs (Docker, the xdg-app bundles etc.). I think Bill's exactly right that the bundling rules don't exist in a vacuum, they're part of a general philosophy of How You Should Get Software which hasn't made much sense for a long time, and so we need to revise them *as part of revising that philosophy*, not just in a piecemeal 'well obviously we need to allow more bundling, cos this isn't working' way. > Similarly, if I'm developing some piece of software that embeds/uses > PostgreSQL, I'm likely targeting multiple distributions, potentially > including Fedora, CentOS, RHEL, Ubuntu, and more. Even if Postgres > is a core > well maintained part of Fedora, I'm not going to care about that > version. > I'm going to pick a constant version and pull it from something like > software collections (or, you know, upstream postgresql.org.) Things like pgsql, for me, are the ones that make this discussion complex, because they can clearly go either way. There are certainly, I think, also cases where you *want* a distro package for it. > Similarly, large ecosystems exist for language infrastructure - > python, JS, > ruby, and more. If there's a compelling case for "package the > entirety of > pip/rubygems/npm, including all versions, in the distro".... I > haven't heard > it. Just use the upstream sources, and build tools to work with > that. That's > what they are there for. I absolutely agree with that - but if we take it as part of a joined- up conversation, it actually *weakens* the case for changing the bundling rules. This is why I agree with you that we need to consider the issues together. I agree with you here: the right answer to the question 'how should I deploy that PHP webapp on Fedora' probably isn't, in all honesty, 'install the distribution package' (there are a few honorable exceptions here, but they're not the majority). So in that case, if we're saying the answer to webapp distribution is not 'package all the webapps', it doesn't necessarily make sense to say 'we should weaken the bundling guidelines to aid webapp packaging'. Perhaps the answer is 'provide integration packages downstream' - stuff like SELinux rules for upstreams who don't make their distributions SELinux-compatible, convenience packages with web server configuration files, whatever. But I guess we shouldn't drive this thread too far off track into discussion of specifics. > To allow or not allow bundling is the small side point here - the > questions > should be more of "Are we a distribution of packages? Are we an OS? > Where > do we see the distribution/OS fit in how software is consumed and > provided? > Is that different for a Workstation vs an Atomic host?" Answer those > big > questions, and the questions on what to do along Ring0->RingN, what > bundling > to allow, etc. should fall out. Absolutely this. Can you please stand for election to something again? :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
