Alec Warner wrote: >> There is no obvious way to freeze a Portage tree (or to design a >> specific profile) for testing on a golden workstation, to build a set of >> update packages (ServicePack) and push it to the workstations, or to >> have centralized accountability of what's installed where. There is no >> easy way to avoid having to keep a synchronized copy of the portage tree >> on all systems, even when using yourown-binaries. > > Network mountable trees seem to work well enough although an emerge > --metadata is still required on clients. > I would disagree also on the profile argument. Profiles are very > powerful, very details, and have decent manpages as well as literally > tons of examples. What specifically is stopping you from rolling your > own profile? > > The rest of that stuff is a generally well known about issue ( at least > in the portage community ). Many features of portage-2.1 will be > helpful in this type of situation.
I probably wasn't clear :) I don't say that it cannot be done, and I don't ask what's the best way to do it. I just ask *if* we should try to provide higher-level tools (and/or doc) to help in doing so. It's not obvious (especially for non-developers) how to proceed in that situation, even if a lot of people have designed their own solution in their corner. >> With automatic deployments, would we run into difficult-to-solve >> etc-update problems ? Should/could the ServicePack system take care of >> that ? > > I wouldn't use etc-update for this on a enterprise rollout personally. > If you need config cfengine does a nice job, as well as using > cvs/rcs/something-else Again, the technology is out there, it's just not tightly integrated. Should we leave it as-is and let everyone design his own tools to connect the dots or should we ? >> Even in a simpler setup (preprod > production) we don't have the tools >> to push a software configuration change from a test machine to a >> production one. > > What exactly are you looking for here? Should we provide high-level software that defines an update pack (new binaries + configuration changes), allows to test it on a preproduction system and (once tested) to push it to registered production systems ? Or let everyone write his own treefreezing + network mounts + shell scripts + cfengine / CVS magic combo to do it ? > Portage needs work; I know the devs are working on it, I know there > are other people who are doing there own things. I see a lot of > portage-2.1 features that greatly simplify what you are trying to do ( > repositories, config rewrite..etc.. ). I think portage and what it > covers is a big part of this. Recollecting a conversation with jstubbs > about portage he mentioned that he wouldn't want the portage-team to > maintain a Enterprise-like distribution program, but that the new API > would be great to write one against ;) I don't think it should be the role of the portage-team either. > I also know Chotchki was looking at doing his senior thesis on a network > aware portage that did some cool things. A lot of this is just waiting > ( and helping :) :) ) the portage devs get the work done that needs to > get done. > > I know Cardoe and genstef? are working on a seperate package manager > that just handles binaries but uses all the current portage stuff, so > you might want to talk to them as well. I sure hope they will comment on that thread :) -- Koon -- gentoo-dev@gentoo.org mailing list
