Skip to content
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

Merged
merged 7 commits into from
Mar 7, 2015

Conversation

vincentbernat
Copy link
Member

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.

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.
….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.
@landscape-bot
Copy link

Code Health
Code quality remained the same when pulling 1d0db5f on vincentbernat:fix/debian-update into 63f8a81 on Exa-Networks:master.

@thomas-mangin
Copy link
Member

@vincentbernat you should be able to push to the repository.
The dependencies presents in requirements.txt may be a good thing to add (as otherwise your code and the test suite will not run) respectively ipaddr and psutil
I think nose could be omitted.

thomas-mangin added a commit that referenced this pull request Mar 7, 2015
@thomas-mangin thomas-mangin merged commit 302e1a8 into Exa-Networks:master Mar 7, 2015
@thomas-mangin
Copy link
Member

And I forgot to be polite and say thank you - I blame multitasking for it 👅

@thomas-mangin
Copy link
Member

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 ?

@vincentbernat
Copy link
Member Author

No, it should stay as is. This is the first version where an empty /etc/exabgp/exabgp.conf is not shipped.

@vincentbernat
Copy link
Member Author

Nope, I cannot push directly to the repository. :)

@thomas-mangin
Copy link
Member

Should work now or I need a GitHub course 😄

@vincentbernat
Copy link
Member Author

You're safe. It worked!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants