Bug#225999: ITP: debsync -- installed packages synchronization tool
Julien BLACHE <jblache@debian.org> writes:
> Arnaud Vandyck <avdyk@debian.org> wrote:
>
> Hi,
Salut,
>> 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.
Why aren't you 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.
$ cat /usr/sbin/apt-proxy | wc -l
1449
$ cat /usr/bin/debmirror | wc -l
839
$ cat ~/debian/debsync-1.0/bin/debsync | wc -l
282
Written in Python with calls to:
DebsyncCommands = { "install" : "PATH=$PATH:/usr/sbin:/sbin apt-get -y install", \
"remove" : "PATH=$PATH:/usr/sbin:/sbin dpkg --purge", \
"list" : "dpkg --get-selections", \
"update" : "apt-get update", \
"rsh" : "rsh -l %s %s", \
"ssh" : "ssh %s@%s", \
}
> 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.
I could not write this (I don't know Python and I'm not an experienced
admin), but with the description you made, I can write a shell script to
do that in less than ten lines! (not with all these options and checks).
> 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)
I don't think it's that simple. And which apt are you talking about?
$ ls /usr/bin/apt* /usr/sbin/apt*
/usr/bin/apt-cache
/usr/bin/apt-cdrom
/usr/bin/apt-config
/usr/bin/apt-extracttemplates
/usr/bin/apt-file
/usr/bin/apt-ftparchive
/usr/bin/apt-get
/usr/bin/apt-howto
/usr/bin/apt-move
/usr/bin/apt-show-source
/usr/bin/apt-show-versions
/usr/bin/apt-sortpkgs
/usr/bin/apt-src
/usr/bin/aptconf-configlet-capplet
/usr/bin/aptitude
/usr/sbin/apt-listbugs
/usr/sbin/apt-proxy
/usr/sbin/apt-proxy-import
/usr/sbin/apt-setup
I'm not sure I have all apt-* installed ;) but also, at the moment, I
only use apt-get, apt-cache, aptitude (and apt-listbugs).
>> 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.
Well, I think it's really a part of the tools a Debian admin *must*
know!
> Besides, there's nothing wrong with easing the job of an admin by
> providing more tools.
I agree, but it's already provided!
> 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)
OK, I don't think the discussion is very constructive here. If you don't
want to discuss or share point of views, go on, upload your script. I
don't wanna discuss anymore with this kind of arguments! It's
ridiculous.
> 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.
That was not in the first description you made from the tool. Maybe
that's why I'm not understanding your point.
> 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.
That was not clear in your definition!
> => 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.
I really don't think so.
--
.''`.
: :' :rnaud
`. `'
`-
Reply to: