To be honest I think that whole current process of package requests is flawed.
There should be a clear overview of what is going on so that both users and sysadmins know what is going on. That mean: there should be a single place to request packages to be installed (bugzilla) and no other places (emails, irc) so that we can track the requests all on one place (people can request stuff on irc, but bugzilla ticket should be made anyway) and there should be also clearly pointed out if someone is working on certain request or not (preferably being assigned to that bug) so that 2 or more people don't work on same package addition. The end result of whole process, should be insertion of requested package to some (nonexisting) list of all packages that were requested and were already installed and bug closed and eventually link to / from that list. So that it is as easy to figure out if package X and Y were already requested and are "somewhere" in puppet or whatever else as opening that list and having a look there if packages X and Y are present there (and if not, request them on bugzilla) This way it would be 100% clear of what is going on with package requests, all nodes would be synchronized, requested packages would be never lost or forgotten, and tool labs wouldn't be such a mess as they are now, when half of exec nodes contain different packages than others and there are many people (including me) who are confused about what is installed or not (and unlike others I can verify that myself, which put me in a better position than other labs users) On Thu, Nov 7, 2013 at 4:40 PM, Petr Bena <[email protected]> wrote: > * never stop coming > > On Thu, Nov 7, 2013 at 4:40 PM, Petr Bena <[email protected]> wrote: >> If we don't make such a list, we will end up having multiple tickets, >> that will never start coming with requests to install same packages >> >> On Thu, Nov 7, 2013 at 4:39 PM, Petr Bena <[email protected]> wrote: >>> I am not talking about "list of installed packages" I am talking about >>> "list of packages that were already requested by other users, are in >>> puppet and guaranteed to be present, so that you don't need to bother >>> us with requesting them again, because they were already requested and >>> are installed" >>> >>> On Thu, Nov 7, 2013 at 4:35 PM, Marc A. Pelletier <[email protected]> wrote: >>>> On 11/07/2013 10:26 AM, Petr Bena wrote: >>>>> From what Tim said, it seems that I should fill in a bug report for >>>>> every single package no matter if it's already in puppet or not, >>>>> because there is clearly no simple way for me to verify that. >>>> >>>> Yes, you should, because otherwise you're relying on implicit >>>> dependencies, which is iffy at best. If you have a tool that needs >>>> libfoo-perl, then you need to make sure libfoo-perl is puppetized and >>>> not rely on the fact that foobar-tools happens to have it as a >>>> dependency and it got installed as a consequence. >>>> >>>> OTOH, never request installation of dependencies of things you depend >>>> on; rely on apt to work those out itself. >>>> >>>> In other words, if your tool invokes 'gizmo' from the package 'gizmo', >>>> list *that* as a dependency, and not the 'libgizmo' it depends on in >>>> turn - you never know when gizmo will switch to libwidget instead. >>>> >>>> This is why making or comparing a "list of installed packages" is >>>> exactly the wrong way to go about things -- there might be things >>>> leftover on nodes from previous versions, or things that were installed >>>> but then never removed (changes in puppet, in general, do not purge >>>> packages no longer explicitly installed). >>>> >>>> -- Marc >>>> >>>> >>>> _______________________________________________ >>>> Labs-l mailing list >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/labs-l _______________________________________________ Labs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/labs-l
