(compound answer, quotes bundled) TL;DR: redhat/ is generic, nothing to be removed, nothing to be added. Much ado about nothing ;)
NB: this mail applies to Linux distributions. I don't know enough about the BSD ecosystem to have an objective opinion. I shouldn't have said anything before about pkgsrc/ and ports/ - apologies. I'll shut up (or investigate properly.) On Sat, Dec 06, 2014 at 10:43:11AM +0000, Paul Jakma wrote: > The distro stuff I added to the repo was added at least in part to make it > easy to build packages straight from the for testing (I dislike doing make > install, and much prefer installing proper packages). E.g. so I could make > dist && rpmbuild -tb quaggga-etc-.tar.gz, or (cd solaris && make > packages). So, it didn't have to be perfect, or with all the latest distro > tweaks, to be useful to me. Yeah, I didn't think of that use case. Shame on me. I doubt this currently works on many platforms, though ;) > It can also life make easier for anyone who finds bugs indistro packages, > and who cometo us, and who we then ask to test our latest release or > master. Again, doesn't need to be perfect or up to date to serve that > function. I wish that was documented somewhere. I certainly missed a few chances to point people to this over the past 2 years... On Thu, Dec 04, 2014 at 10:50:30PM -0500, Alexis Rosen wrote: > David, I think you're missing an important point: Quagga has a much > greater interest in being available on many platforms, than individual > platforms/distros have in making quagga available. > [...] > Because of this I think it's in the project's interest to keep init > scripts around, and getting rid of them is a false economy. My argument was that the init scripts we have around *don't* make it easier for any of the distros, and possibly confuse users (because they don't match up with what the distro installs - some distros use a single init script for all daemons for example!) If a distribution needs to customise a file, two things work well: copying the example file and modifying it, or using a distro template and adapting it (possibly while looking at the example file). Both of these result in a file that is fully under the distribution's control. Changing it is easily done within the distro's procedures. What doesn't work well is including an upstream file and applying changes - not only is a patch file or sed command more complex to deal with (because changing the file is now changing a change), but also on every new upstream release, the changes may need rebasing, probably for no good reason. Submitting the changes upstream is not a good solution because it's now possibly a multi-week e-mail thing instead of a git push or so. Cf. the citation below from Debian requesting packages to not include a debian/ directory. But, that said: On Fri, Dec 05, 2014 at 04:06:01PM -0500, Alexis Rosen wrote: > I disagree that they hurt more than help. For someone with minimal > experience with quagga (most distro package maintainers), a 90% right > starting point is way better than a 0% starting point. Of course, the > closer to perfect we can get them, the better. I do agree with this. I think this is served along the same axis as the above "have some minimal packaging for users & testing." We should keep some generic/demo init scripts around so the package maintainers can scroll through and adapt their own distro template scripts. So I would like to take/change to this position: (This applies to Linux, I don't have an opinion on the BSD stuff.) - We do ship "one of everything", i.e. a set of generic init scripts, .service files, logrotate config. If there's an easy way to provide "side" package-building (e.g. spec file), we keep that around too. (This implies redhat/ is misnamed and needs a new name.) - If we can make things more generic, we should. Not sure to what extent this is the case. - We don't ship things specifically adapted to a particular distribution. Anything in tree should be usable on at least 2 different distros that create their own Quagga package. NB: this doesn't mean it's used by the packaging process, just that it has some point of applicability. This is the data I'm basing my arguments on: First, Debian explicitly discourages shipping Debian build directories in release tarballs: [https://wiki.debian.org/UpstreamGuide]: "Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort. Keeping it only in your VCS repository is usually a much saner default." Which, even though they don't prescribe against keeping it around, does imply that they _don't_ want debian/ coming from upstream for their actual packaging. (This is the stance I assumed they would have, while making my arguments.) I couldn't find statements in this regard from other distributions, in any direction (including or not including specific things). Now, for usage of the files bundled in Quagga: * .spec init systemd sysconf logrot. PAM Alpine - custom - - - - Arch - - custom - sed - Debian - custom - - custom custom Gentoo - custom - - used custom Mageia custom - custom used used used OpenSuSE custom custom - - used custom Rawhide custom - patch used used - Slackware - custom - - custom custom (Rawhide was the easiest to find for Fedora. I listed as many as I could comfortably find, no claim to this being an exhaustive list!) - None of the distributions use Quagga's .spec file. - None of the distributions use Quagga's init scripts. - Fedora is the only distribution to use Quagga's systemd .service files, but only with patching. - Mageia and Fedora use the sysconfig file. - A lot of distributions use the logrotate definition file, which is funny because without user intervention Quagga doesn't even log anywhere - SuSE creates a default config with log statement though, very nice! - Mageia is the only distribution to use Quagga's .pam file. On Sat, Dec 06, 2014 at 07:25:18AM -0800, Dinesh Dutt wrote: > I agree with what Alexis is saying. At least when it comes to the > multi-instance patch, making the thing work without requiring > modifications of watchquagga or any other program certainly requires > some crucial changes to the initd script quagga uses for start/stop. Applying the above reasoning, I would suggest you change the generic init scripts and systemd service files in redhat/. (Also: watchquagga should probably be modified to support MI ospf) -David _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
