Frosty555
asked on
Creating a debian repository for squeeze and lenny
Hi guys,
Our company hosts packages of our own software on a local repository on our network. Right now it is what this guide refers to as a "trivial repository"
http://www.debian.org/doc/manuals/repository-howto/repository-howto
Our current development platform is Debian lenny, but we'd like to move to Debian squeeze. The problem is that our product's custom made packages, which we put into our local repo, are not compatible between the two. I have to tweak some dependencies and there are some minor code changes needed to make it work on squeeze.
Ideally, I'd like to make a fork of our project just for squeeze, and build "squeeze" specific packages.
How can I change the repository so that I have one set of "lenny" packages available for lenny machines, and another set of "squeeze compatible" packages are available for squeeze machines?
Below is an example of my sources.list:
And an example of the tree structure in our Repo:
You can see how unlike the regular debian repos, our local one doesn't explicitly say "lenny" on it anywhere - so those packages show up no matter what version of linux we're using.
How do I change our local repository and/or my sources file so that I can make packages that differentiate between lenny and squeeze?
Our company hosts packages of our own software on a local repository on our network. Right now it is what this guide refers to as a "trivial repository"
http://www.debian.org/doc/manuals/repository-howto/repository-howto
Our current development platform is Debian lenny, but we'd like to move to Debian squeeze. The problem is that our product's custom made packages, which we put into our local repo, are not compatible between the two. I have to tweak some dependencies and there are some minor code changes needed to make it work on squeeze.
Ideally, I'd like to make a fork of our project just for squeeze, and build "squeeze" specific packages.
How can I change the repository so that I have one set of "lenny" packages available for lenny machines, and another set of "squeeze compatible" packages are available for squeeze machines?
Below is an example of my sources.list:
deb http://ftp.ca.debian.org/debian/ lenny main
deb-src http://ftp.ca.debian.org/debian/ lenny main
# our local repository
deb http://192.168.1.55/mirror/repo binary/
And an example of the tree structure in our Repo:
repo
|-- binary
| |-- Packages
| |-- Packages.gz
| |-- ourproduct_10.10-3057_all.deb
| |-- ourproduct_10.11-3068_all.deb
| |-- ourproduct_11.0-3160_all.deb
| |-- ourproduct_11.2-3174_all.deb
| |-- ourproduct_12.1-3188_all.deb
You can see how unlike the regular debian repos, our local one doesn't explicitly say "lenny" on it anywhere - so those packages show up no matter what version of linux we're using.
How do I change our local repository and/or my sources file so that I can make packages that differentiate between lenny and squeeze?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
it needs to be built for every environment of course.
And that might be more tricky than you think. If you need some feature from a library that is different from one set to another, that might give you a challenge.
(I used to have such problems in the past with RedHat, they provide a long term stable platform, but sometimes i need a faster moving platform and then there are conflicting libraries, depending on the mixed you need).
Esp. openssl might break between versions (by design, to prevent continued use of defective libraries).
And that might be more tricky than you think. If you need some feature from a library that is different from one set to another, that might give you a challenge.
(I used to have such problems in the past with RedHat, they provide a long term stable platform, but sometimes i need a faster moving platform and then there are conflicting libraries, depending on the mixed you need).
Esp. openssl might break between versions (by design, to prevent continued use of defective libraries).
ASKER