-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debian packaging update #236
Debian packaging update #236
Conversation
There is little interest to keep a complete changelog with just automated messages. Let's just keep one entry. Also, ensure we can update to the "official" packaging if we want to by ensuring we use a version number inferior to the one used in Debian/Ubuntu.
Also, convert it to DEP-5 format.
Using an environment variable to check if we should start the daemon is now considered bad practice. If the user installs the daemon, they want it to start with a "good" default configuration. Since it is quite difficult to have a good default configuration with ExaBGP, we just don't ship a default /etc/exabgp/exabgp.conf and won't start if the file is not present. As soon as the user adds its own configuration file, the daemon will be started. If a user doesn't want to start the daemon, they should use the appropriate mechanisms for that. For example, `systemctl disable exabgp.service`. exabgp.env is now generated with the default settings from ExaBGP and we ask the user for confirmation before erasing (through ucf). There is no more reading configuration from /etc/default/exabgp. This simplifies the install/removal scripts. systemd service file is also updated to start only if the configuration file exists.
Also, small cosmetic changes.
….4.9 Otherwise, the user will get this message at each upgrade: Obsolete conffile /etc/exabgp/exabgp.conf has been modified by you. Saving as /etc/exabgp/exabgp.conf.dpkg-bak ... While it makes sense the first time, it is quite pointless the next time and a user may be troubled by it.
@vincentbernat you should be able to push to the repository. |
And I forgot to be polite and say thank you - I blame multitasking for it 👅 |
I see that debian/exabgp.preinst does reference the latest version number, should this file be generated from setup.py when I tag a new release ? Or should the code be able to determine the version from the packaged files ? |
No, it should stay as is. This is the first version where an empty |
Nope, I cannot push directly to the repository. :) |
Should work now or I need a GitHub course 😄 |
You're safe. It worked! |
Hey!
Updates for Debian packaging.
The important change is the fourth one, about not relying on the content of /etc/default/exabgp to start the daemon. This is considered bad practice. Instead, I rely on the presence of /etc/exabgp/exabgp.conf to start the daemon (including for systemd). The package doesn't ship
/etc/default/exabgp
anymore (useless) and we don't ship/etc/exabgp/exabgp.conf
either. Previously, an empty configuration file was shipped. The post/preinst scripts are taking care of the migration. A user that did not modify/etc/exabgp/exabgp.conf
will see the file removed while a user who did modify the configuration will keep it.