[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: dak setup



Hi Paul,

Thanks for your post. I checked the log - there was nothing in it. I'm not clear what you mean by "signed uploads", and you're probably wondering why, if that's the case, I'm trying to use dak at all.

I probably need to explain where I'm coming from re. this. For over 10 years, I've been working with RPM-based repositories (Fedora, CentOS, etc.) and using them to install/update a large number of workstations. The used method is to create local regularly-updated mirrors of repos on the net, create non-mirrored copies of them, and then install the workstations from the non-mirrored copies. Periodically, the updates brought in by the mirroring are checked, and updates which we require are copied from the mirrored to the non-mirrored repos and the repo metadata is re-created (in the RPM world, this requires running the tool createrepo, and is fairly trivial.) After this, the copied updates can be installed on the workstations. The main reason that we go through this tortuous process is that we run some software which has a large number of prerequisite packages and is very picky about the versions of these (to the point that if we apply an unexpected update to one of the prerequisites, we risk the software breaking, and possibly corrupting the database which it maintains.)
 
A few months ago, I was asked to set up a similar environment to enable workstations to run ubuntu as an alternative to the RPM-based systems. I now have the two sets of local repos (mirrored (using apt-mirror) and non-mirrored,) and workstations are being successfully installed from the non-mirrored repos. The piece of the puzzle which is missing is a way of copying selected packages from a mirrored repo to a non-mirrored one, and then regenerating the metadata in the non-mirrored repo. I've already tried setting up a very basic single-directory repo, creating a .deb package in it, and using dpkg-scanpackages to create the Packages.gz file - this worked, and once the URL to the repo was accessible from a workstation, the packages in it could be installed. The problem is that this won't work for a full-scale mirror of a dists/pool repository (although I'm aware that it's basically a process of collecting all the control data from the packages in the pool, working out to which area in the dists hierarchy each package relates, and then re-creating the Packages.gz files from the data: I'm tempted to have a go at writing something from scratch.)

I've been exploring dak in the hopes that I could get it to do the above - but I'm starting to get the feeling that it may be either inappropriate or overkill. Is this correct? If not, is there something simpler which might do the job? 

I'm really sorry for the length of this post.

Regards,
Peter

-----Original Message-----
From: Paul R. Tagliamonte [mailto:paultag@gmail.com] 
Sent: 24 February 2015 22:21
To: Duffy, Peter
Cc: debian-dak@lists.debian.org
Subject: Re: dak setup

You place signed uploads into the unchecked directory -- checking the log might be a good start!

Check that it's got a valid sig from a key in the keyring

  Paul


Reply to: