Bug#225999: ITP: debsync -- installed packages synchronization tool
Arnaud Vandyck <avdyk@debian.org> wrote:
Hi,
> I don't understand. If I make a script (with a loop!;)), why can't I put
> it in a cronjob? Also, note that the --set-selections needs to be done
> once (or everytime you add/remove a package on the master host), all the
> other times it's only an update.
I think you're missing part of the problem here, but I'm not really
/that/ surprised.
>> What's important here is *having* the _tool_. The fact that it does
>> what you could do in 5 commands is irrelevant. And if you were to
>> write the script yourself, you'd have to test/debug it, etc.
>
> I don't agree.
Rather you're not getting the point.
Take apt-proxy or debmirror as examples. debsync falls into the same
category : it could be written by the people who need it, but having
it already written and packaged in the distro has its advantages :
more features, more testing, less bugs. It's simply convenient.
In fact, you don't even need apt. You can reimplement it with wget and
dpkg and some bash script to glue them together. (credit: benj)
> 2° If every scripts have to be package, I think we'll have some problems
> in the distro! Also, note that ssh and aptitude are tools that must
> be known by the average administrator (and I think your tool is for
> admins, not users who don't have the right to install anything). And
> if this admin read some docs about Debian, he'll learn dpkg fast!
You'd be very surprised by the number of admins that do not know some
simple dpkg commands. Incompetent admins aren't an endangered species.
Besides, there's nothing wrong with easing the job of an admin by
providing more tools. We could also ship our packages as tarballs,
have non-bootable CDs without an installer and any good admin should
be able to unpack that on any machine. (no Slackware troll intended)
Ideally, I'd like debsync (or another piece of software) to be able to
cope with apt pinning for instance. And synchronize apt config files
too.
Oh, and I'd like to define classes of remote hosts, with per-class
include/exclude lists (think kernel, think different
architectures). And a test-mode that would run on a test host defined
for each class, before running the update for the whole class.
=> A tool that would make my life easier
I don't know of/if debsync will evolve, but if it doesn't I'll
probably end up writing that tool myself.
>> I hope you see my point now :)
>
> I think, but do you see mine?
Yup. I've seen it long ago already, believe me... Go get a clue.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jblache@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Reply to: