bugs.michael@xxxxxxx said: > It ought to be a warning, not another hurdle which requires packagers, who > know their stuff, to "fight" with automated tests and questionable results. > Even if there were a simple way to disable such tests, it makes using the > entire package maintenance environment less comfortable. I am trying to deal with: - package staying within the packaging guidelines, one of which being an acceptable rpmlint output - unwanted things being suddenly provided by unexpceted packages - spurious soname changes - get to a point where it is pretty safe to have an automated rebuild of everything and be somewhat confident that the outcome is not completely broken > And: *boom* At this point in the queue of build jobs, other packages now > fail or cause errors, since: > a.) they require the results of earlier build jobs > b.) they depend on later build jobs to be published Yes. The hope is that it will only go *boom* for valid reasons. > c.) rpmlint at the server is not the same as packager's rpmlint ;) Could happen, but a new rpmlint error is probably something that needs to be dealt with. > Additionally, packagers need to make rpmlint shut up at the buildsys level > when it is mistaken about the things it finds and reports. Huh? Can you elaborate on this ? > Bad extra burden. Maybe. But I'm not so sure it's such a burden. All of this should be automated. > Unless it is fully optional and can be requested by > packagers explicitly for a "scratch target". Maybe that's a way to get there. > It will create so much additional traffic that less community people will be > able to handle it, and the important changes at the spec file level will be > monitored by even less people. My hope is that reference files will be more stable than the package files, so less traffic to monitor in the end. > As a first step, every packager (and package submitter) ought to use rpmlint > manually more often and run it also on the binary rpms. AFAIK, rpmlint is mostly useful on binary rpms. I'd just like to automate its use in a useful way. But these are just ideas. You are welcome to dislike them and/or offer other, better ones. Cheers, Christian -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
