Hi All, I'm trying to find a solution to a problem. I would like tie apt (or dpkg) to some kind of version control system so every time you install/remove a package you much annotate why you're doing so. The reason i'd like to have a system like this is because i co-maintain a linux machine with a few other people and we'd like to keep a running tally as to who installed what packages and why (since the package gets unwieldy after a while). Does anyone know of a system like this? The closest thing i was able to find was something called pkgwatch, which is a package of scripts which wraps around apt and rpm; one of it's features is to diff the list of packages after every call to apt-get which will get the job done. Does anyone know of anything similar? Thanks, -- Brad
I'm trying to find a solution to a problem. I would like tie apt (or dpkg) to some kind of version control system so every time you install/remove a package you much annotate why you're doing so. The reason i'd like to have a system like this is because i co-maintain a linux machine with a few other people and we'd like to keep a running tally as to who installed what packages and why (since the package gets unwieldy after a while).
Hmm...maybe just telling everyone they need to run using sudo apt-get ... would be enough? And log the logs?
Does anyone know of a system like this? The closest thing i was able to find was something called pkgwatch, which is a package of scripts which wraps around apt and rpm; one of it's features is to diff the list of packages after every call to apt-get which will get the job done. Does anyone know of anything similar?
Sorry, I don't. Sounds like you want 'cvs-apt-get' which is a wrapper around apt-get which logs changes and asks for a commit message each time. Shouldn't be too hard, again with Sudo to force. Then have tripwire monitor the system to look for other changes. Dunno... even in my team environments, we just make sure to email the rest of the team to discuss new packages or just let people know you put something on. John
You could also write a script named apt-get and stick it in the PATH before the real apt-get, Have it call the real apt-get and log the parameters and username? You could also have it automagically sudo for the user too. to make things easier. On Sat, Mar 14, 2009 at 12:49 PM, John Stoffel <john@stoffel.org> wrote:
I'm trying to find a solution to a problem. I would like tie apt (or dpkg) to some kind of version control system so every time you install/remove a package you much annotate why you're doing so. The reason i'd like to have a system like this is because i co-maintain a linux machine with a few other people and we'd like to keep a running tally as to who installed what packages and why (since the package gets unwieldy after a while).
Hmm...maybe just telling everyone they need to run using sudo apt-get ... would be enough? And log the logs?
Does anyone know of a system like this? The closest thing i was able to find was something called pkgwatch, which is a package of scripts which wraps around apt and rpm; one of it's features is to diff the list of packages after every call to apt-get which will get the job done. Does anyone know of anything similar?
Sorry, I don't. Sounds like you want 'cvs-apt-get' which is a wrapper around apt-get which logs changes and asks for a commit message each time. Shouldn't be too hard, again with Sudo to force.
Then have tripwire monitor the system to look for other changes.
Dunno... even in my team environments, we just make sure to email the rest of the team to discuss new packages or just let people know you put something on.
John _______________________________________________ Wlug mailing list Wlug@mail.wlug.org http://mail.wlug.org/mailman/listinfo/wlug
On Sat, 14 Mar 2009 21:05:11 -0400, Jason Couture <plaguethenet@gmail.com> wrote:
You could also write a script named apt-get and stick it in the PATH before the real apt-get, Have it call the real apt-get and log the parameters and username? You could also have it automagically sudo for the user too. to make things easier.
This actually ended up being the approach i took. I didn't want to make a wrapper around apt-get because packages can be installed through apt-get, dpkg, aptitude. The solution that i made was to wrote a script called dpkg.py and configure apt to call that script instead of dpkg; this can be by adding Dir::Bin { dpkg "/home/brad/local/bin/dpkg.py"; }; to apt.conf. My dpkg.py is simply a wrapper around dpkg which parses out the command line arguments to determine which packages are being added/removed; it also uses SUDO_USER to determine the user who called sudo. if anyone wants this script let me know, i'll be happy to email it out. It's somewhat crudely written in python with some hardcoded paths (i started to do it in bash/zsh, but had a hard time parsing out the command line args).
On Sat, Mar 14, 2009 at 12:49 PM, John Stoffel <john@stoffel.org> wrote:
I'm trying to find a solution to a problem. I would like tie apt (or dpkg) to some kind of version control system so every time you install/remove a package you much annotate why you're doing so. The reason i'd like to have a system like this is because i co-maintain a linux machine with a few other people and we'd like to keep a running tally as to who installed what packages and why (since the package gets unwieldy after a while).
Hmm...maybe just telling everyone they need to run using sudo apt-get ... would be enough? And log the logs?
the logs doesn't get the user who executed the script. I thought about parsing out the logs, but i thought i could make a better solution.
Does anyone know of a system like this? The closest thing i was able to find was something called pkgwatch, which is a package of scripts which wraps around apt and rpm; one of it's features is to diff the list of packages after every call to apt-get which will get the job done. Does anyone know of anything similar?
Sorry, I don't. Sounds like you want 'cvs-apt-get' which is a wrapper around apt-get which logs changes and asks for a commit message each time. Shouldn't be too hard, again with Sudo to force.
As i mentioned above, the wrapper approach ended up being how i did it. apt also has hooks to run scripts before and after package additions with a pre-invoke and post-invoke scripts, but it's hard to determine which packages are being added this way. Wrapping dpkg seems to be the best way, at least as far as i've figured out.
Dunno... even in my team environments, we just make sure to email the rest of the team to discuss new packages or just let people know you put something on.
Yeah, this seems like a logical approach, but requires way too much diligents. i think i speak for the other admins on this machine by saying i'm way to lazy to email every time i add a package. If this were for work, i might take this approach, but since this is a recreational machine, laziness wins out.
Thanks, -- brad
My dpkg.py is simply a wrapper around dpkg which parses out the command line arguments to determine which packages are being added/removed; it also uses SUDO_USER to determine the user who called sudo.
apt-get will also install dependencies of the packages you specify. A simple command line parsing script wouldn't catch this. Perhaps you handle this already or don't care to track individual libraries. However, It seemed important enough to mention.
On Tue, 17 Mar 2009 10:01:27 -0400, James Gray <jamespgray@gmail.com> wrote:
My dpkg.py is simply a wrapper around dpkg which parses out the command line arguments to determine which packages are being added/removed; it also uses SUDO_USER to determine the user who called sudo.
apt-get will also install dependencies of the packages you specify. A simple command line parsing script wouldn't catch this. Perhaps you handle this already or don't care to track individual libraries. However, It seemed important enough to mention.
Yes, apt-get and aptitude automatically figure out dependencies and install them, but both apt-get and aptitude call dpkg, or whatever you have the dpkg variable set to in apt.conf, with a list of packages to install (or remove). For example if you run 'apt-get install emacs' apt will download the necessary packages/dependencies and then eventually call 'dpkg --configure emacs emacs22-common emacsen-common emacs22-bin-common emacs22-gtk'; so if you wrap dpkg you'll get a list of all the packages that are installed/removed since all package additions, whether they're dependences or not, are done through dpkg, regardless if you use apt-get or aptitude or install one package or many packages w/ and w/o dependencies. Actually the nice thing about apt is that the people who wrote apt went through great pains to make sure dpkg is called a minimal amount of times; twice for package(s) installation, first for unpacking a package(s) then again to configure the package(s). For package removal dpkg is only called once. This is really nice because if i wrote inefficient code my wrapper will still only get called twice at most, even if i decide to install 100 packages at once. If dpkg was called 100 times to install 100 packages, that would drastically increase the time complexity of installing packages, especially if it's running my code :). -- brad
participants (4)
-
bkn＠ithryn.net -
James Gray -
Jason Couture -
John Stoffel