On Mon, Feb 20, 2017 at 7:24 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Mon, 2017-02-20 at 18:24 -0500, Neal Gompa wrote: >> I for one don't actually want Rawhide to be gated because it makes >> things much harder in terms of properly developing new features. We're >> simply not capable of being as good as OpenSUSE in terms of automation >> to be able to pull off the feats they do. There were major changes to >> how OpenSUSE did packaging to begin with to be able to pull off what >> they did, and I simply don't think anyone here is prepared to do even >> a small bit of that yet. > > This is vague and non-actionable. What, specifically, do you think will > be a problem, and what, specifically, do you think needs changing to > fix the problem? So, off the top of my head, there are a few things here: * Version-Release formatting in Fedora packages is too complicated. We store part of the upstream versioning in the Release field, making it way more difficult to safely and sanely bump the release automatically. Moving that information out of Release and back into Version (where it belongs) drastically simplifies the Release field, which leads to... * Automatic rebuilding of dependency chains and submitting them as part of updates. Right now, it's a ton of work to go through and find the reverse dependencies of a package and build that chain and submit it as part of an update. It should be that once someone has updated a package past some kind of dependency drift point (could be any update bumping the version or based on library soname or whatever), the reverse dependencies should automatically be calculated, bumped with an automatically generated changelog entry and release field bump, and appended to an update (or just rebuilt and merged right back in after an update package is pushed). There is way too much grunt work involved in building dependency chains, and we don't seem to have any will to fix that. Koschei already does a lot of this with scratch building, but I do not think they should be scratch builds, and instead should be actually submitted. * We need actual post-build checks to occur right after the build, using rpmlint and other tools. Right now, no one knows *anything* about the usefulness of a package until we submit to Bodhi. That's *way* too late in my view, and doesn't even make sense. As far as I know, Koji has some (weak) support for post-build checks like SUSE's OBS has, and we should be incorporating things like rpmlint, package scans, etc. that Taskotron does as part of a post-build check *before* updates are submitted. And the general disdain for package linting needs to die. Being sloppy with our packaging because we can't know whether our own tools are telling us the right thing is a terrible thing. Some other nice-to-haves that should probably make our lives a bit easier: * Finding ways to eliminate Epoch as a general matter of consideration for packagers. That means figuring out how to retool Fedora so that Epoch doesn't need to persist beyond a single release. We can already handle this with distro-sync in DNF, but if there are other pieces, they need to be fixed up too. At first glance, this doesn't seem like something all that important, but Epoch throws people off quite a bit when setting up package dependencies, because it's not a field that we usually use, and it's not always obvious when we're using it. Not to mention, now that we don't actually need it to ensure upgrade paths, we should try to get rid of it whenever we can. And this business of "rawhide going down being bad" needs to die in a fire, since nobody should be reasonably NOT using distro-sync in Rawhide or going to a new Fedora release. * Pushing to eliminate more scriptlets that people have to drop into packages. Either turn the scriptlets into one-liner macros, turn them into file triggers, or turn them into some kind of inotify thing so that people *do not have to think about them*. Ideally the Scriptlets page in the wiki[1] should be nearly all including warnings that they aren't to be used in Fedora. We've actually made some good progress on this, but we've stalled out a bit... * A dedicated application for doing package reviews. Bugzilla is horrible for this. If you think Bugzilla is a good tool for this, then you have Stockholm Syndrome somehow, because it's a really crappy workflow. Ideally, it should be something that plugs into our build infrastructure, so that as changes are made during a package review, they are tracked and the reviewer can see the differences as they come. OpenSUSE's OBS actually has this built into their system. The "submit requests" provide exactly the same functionality in a rather lightweight manner, and allow reviewers to look at *everything*, including the contents of tarballs being submitted, if they want to. Having a dedicated application that also does things like enable the reviewer to go through the fedora-review checklist quickly and accurately would make things much smoother. There's probably more, but I can't remember all the things right now... [1]: https://fedoraproject.org/wiki/Packaging:Scriptlets -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
