On Thursday 18 June 2009 04:47:45 Goswin von Brederlow wrote:
> Frank Lin PIAT <fpiat@klabs.be> writes:
> > On Tue, 2009-06-09 at 16:16 -0500, Joseph Rawson wrote:
> >> On Tuesday 09 June 2009 13:14:53 sanket agarwal wrote:
> >> > This can be stated as: if a person
> >> > wants to keep a customised set of packages for usage with the
> >> > distribution, the tool should be able to develop dependencies, fetch
> >> > packages, generate appropriate documentation and then create the
> >> > corresponding directory structure in the target mirror! The task can
> >> > be extended to include packages which are currently not under one of
> >> > the standard mirrors!
> >
> > <lazy-way>
> > One don't have to merge the repositories, one can just declare multiple
> > sources in /etc/apt/*
> > </lazy-way>
>
> Lets say I want to mirror xserver-xorg from experimental. Then I would
> want it to include xserver-xorg-core (>= xyz) also from experimental
> as the dependency dictates but not include libc6 from experimental as
> the sid one is sufficient.
>
> A key point here would be flexibility.
This is something that I haven't considered yet. This would be one of the
problems that might occur with the "post invoke hook" that you mentioned
earlier using dpkg status. Actually this wouldn't be much of a problem, I
was confused. I was thinking you were meaning "--get-selections" which just
returns the name of the package and "install/deinstall", but status also
contains the version being used, and this could be matched to the appropriate
repository in the sources list (so you get the libc from main instead of
experimental, since the status file uses the version that's in main).
However, I don't know how to use that info with reprepro. With reprepro, I've
only sent "--get-selections" lists to it. In fact, this is how I used to
install new packages in sid, and make sure they came from the local
repository first.
------------------------------------
#!/bin/bash
packages=`grep-status " install ok not-installed" | grep Package |
gawk '{print $2}'`
#packages=`aptitude search ~N | grep ^.i | gawk '{print $2}'`
touch conf/list-uninstalled.tmp
for package in $packages
do echo -e "$package\t\tinstall" >> conf/list-uninstalled.tmp
done
cat conf/list-uninstalled.tmp | uniq | sort > conf/list-uninstalled
rm conf/list-uninstalled.tmp
------------------------------------
You may be able to tell by looking at the script that I'm still in the process
of getting used to aptitude, being a longtime dselect user. ;)
Anyway, I don't know much about determining (with reprepro) which upstream
repository holds the version of the package that I want installed.
>
> >> > I think the tool can have immense utility in helping people automate
> >> > the task of mantaining the repositories. Suggestions, positive and
> >> > negative are invited.
> >> >
> >> > I have not included the impl details as I would first like to evaluate
> >> > the idea at a feasibility and utility level.
> >
> > If the scope of your project includes being able to bootstrap systems
> > from the mirror, resolving dependency is much more complex (some
> > packages aren't resolved by dependencies. For instance, the right kernel
> > is select by some logic in Debian-installer).
> > I found some interesting logic in debian-cd package.
>
> You would include "linux-image-<type>" in your package list. That
> isn't really a problem of the tool. Just of the input you need to provide.
> Also you would include everything udeb and everything
> essential/required for bootstraping purposes.
>
I was also thinking along those lines, too. Same with fam/gamin and other
packages that have "drop-in" replacements.
> Again flexibility is the key.
>
> > Still, I don't consider that allowing bootstrapping is mandatory. Your
> > project would still be extremely valuable without it. [for those 95% of
> > the people that install from CD, as opposed to netboot].
> >
> > Regards,
> >
> > Franklin
>
> MfG
> Goswin
>
> PS: the essential/required packages can already easily be filtered
> with grep-dctrl.
--
Thanks:
Joseph Rawson
Attachment:
signature.asc
Description: This is a digitally signed message part.