This is not useful per se, but it becomes so when you use custom distributions names to distinguish separate product branches.
Let's assume you have an application app, which has different flavours, for example alpha and beta.
You may want to have two separate debian repos for app, one called alpha and one called beta.
Hosts within environment A may refer to the alpha repo, while hosts in another environment, let's say environment B, may want to refer to the beta repo.
This keeps the small or big differences in app isolated.
Now, assume app reaches a point when the only difference between A and B is the distribution name, so you can have the same version for the alpha and beta repo: how can you avoid building the package twice? Is there a way to make both repos happy?
These are the questions that led me to the need of having a local debian repo, to experiment a little on this topic (I know I should read all the Debian Policy docs and come up with one, single, incontrovertible answer. But I prefer the empirical way, sometimes).
So far I've just created a local repo using reprepro, and following this easy tutorial. I'll update this post with a simple procedure to build your own repo and some results on how to manage the distributions (although I must admit that in this particular moment I expect a simple solution to be:
1. Just stick both distributions inside debian/changelog
or
2. Add a Provides directive to debian/control
)
No comments:
Post a Comment