On 8 March 2010 22:00, Dave Hall <dave.h...@skwashd.com> wrote:

> Hi Paul,
>
> On Mon, 2010-03-08 at 20:44 +1000, Paul Gear wrote:
> > Hi folks,
> >
> > I thought i'd ask a technical question here to give us a bit of relief
> > from the leadership structure and all that.  :-)
> >
> > I have previously maintained my own software repository for my Debian
> > systems, but it fell into disuse.  When i came back to re-visit the
> > question, i found that the ballgame had changed, and my scripts to
> > maintain my site (they used dpkg-scanpackages and dpkg-scansources)
> > don't work any more.  I found this page which talks about tools to
> > create my own repository:
> > <http://wiki.debian.org/HowToSetupADebianRepository>.  That page
> > doesn't seem to nominate a clear winner, and lots of the products seem
> > to be poorly documented or abandoned.
> >
> > Here are the factors in my repository creation equation:
> >      1. I need to support Debian & Ubuntu, both i386 & amd64 (but
> >         preferably all architectures) with one repository and one
> >         build process.
> >      2. Most of my packages are small and architecture-independent
> >         (perl scripts, Java programs, and the like), but i don't want
> >         to be limited to this.
> >      3. I want to run the repository on my own LAN to provide maximum
> >         speed and availability to my servers - this rules out using
> >         PPA.
> >      4. I want to use a product that is under active development
> >         and/or use by Debian and/or Ubuntu developers - this means it
> >         should be available in main or universe.
> >      5. I'd prefer to maintain as few repository management files as
> >         possible.  The archive will not get big and complex, so it's
> >         OK to maintain some by hand, but i'd rather not.
> >      6. I want to keep all older versions of my packages online.  (My
> >         old scripts used to complain every time i uploaded a new
> >         version because there were already 27 existing versions in the
> >         repository.)
> >      7. I'd prefer to find something that is reasonably
> >         well-documented, because asking Debian developers for help is
> >         like extracting blood from a stone (just try #debian on IRC
> >         sometime if you don't believe me), and Ubuntu folks tend to
> >         look at you all weird-like when you don't want to do
> >         everything through launchpad & PPA.
> > Is this a reasonable list?  Is there a product that fits the bill?
>
> I can't help with the build side of things, all my package building
> isn't automated.  For the serving of packages I use reprepro and nginx,
> for info check out the blog post I prepared earlier
>
> http://davehall.com.au/blog/dave/2010/02/06/howto-setup-private-package-repository-reprepro-nginx
>
> I think it ticks all the boxes except #6 out of the box, but a quick
> shell script should help with the archiving bit.  I keep all of my
> packaging stuff in version control so I don't need to keep old versions
> kicking around.
>
> Cheers
>
> Dave
>
>
I'll second Dave's suggestion of reprepro and nginx.

The comment at the end of Dave's blog post was mine, and I have since moved
from using apache to nginx too.

I use pbuilder to maintain a few packages for the systems I maintain. From
pbuilder I target amd64 & i386, jaunty & karmic. I know pbuilder also
supports building to debian targets on the same system too, but have not had
a need to try it yet.

>From there I debsign the .changes files and import them into reprepro.
Nginx serves that repo to my local lan and also proxies approx running on
the same machine too. This gives me a both the an upstream proxy and a my
local packages with a couple of simple lines in sources.list.
eg:
deb http://apt/ubuntu karmic main
deb http://apt/ubuntu karmic-updates main
deb http://apt/ubuntu karmic-security main
deb http://apt/internal karmic main

Ubuntu being the upstream proxy and internal being my local package
repository.

In my situation, to keep old versions around I would archive them to a
folder nginx serves as they are built as reprepro does a good job of keeping
your repo current and clean. I have not got around to throwing everything
into VC, but that's going to be my next step and a big recommendation from
me too.

Just to muddy the waters for you a little. :-)

- Karl
-- 
ubuntu-au mailing list
ubuntu-au@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-au

Reply via email to