Has anyone had good/bad experiences with smart? Looks like the ideal
way to maintain your system at first glance.
--
Collins
When I saw the Iraqi people voting three weeks ago, 8 million of them,
it was the start of a new Arab world.... The Berlin Wall has fallen.
- Lebanese Druze leader Walid Jumblatt
On Sat, 2005-03-26 at 10:18 -0700, Collins Richey wrote:> Has anyone had good/bad experiences with smart?--- good ---> Looks like the ideal > way to maintain your system at first glance.--- seems that way to me too Craig
On Sat, 2005-03-26 at 11:27, Craig White wrote:> On Sat, 2005-03-26 at 10:18 -0700, Collins Richey wrote: > > Has anyone had good/bad experiences with smart? > --- > good > --- > > Looks like the ideal > > way to maintain your system at first glance. > --- > seems that way to me tooIt looks like it may help with the ''multiple conflicting repository'' issues, but there are some other problems with existing tools. Does it add any way to (a) make sure the repository is in a consistent state during the update, and (b) perform updates on production machines making sure that they get exactly the same packages that have been previously tested, regardless of subsequent additions to the repository? The yum maintainers have suggested keeping 2 local mirror copies of the entire repository to accomplish this (with associated config changes and manual package copying) but that seems like a horrible amount of overhead just to make a tool work predictably. Couldn''t something like subversion be put under the covers to allow atomic commits of all dependent packages at once into the repository and allow upgrades (or downgrades) to tags or timestamps? This seems like a job that needs exactly the set of functions provided by a revision control package. -- Les Mikesell les@futuresource.com
On Sat, 26 Mar 2005 11:54:10 -0600, Les Mikesell <lesmikesell@gmail.com> wrote:> > It looks like it may help with the ''multiple conflicting repository'' > issues, but there are some other problems with existing tools. > Does it add any way to > (a) make sure the repository is in a consistent state during > the update, and > (b) perform updates on production machines making sure that > they get exactly the same packages that have been previously > tested, regardless of subsequent additions to the repository? > > The yum maintainers have suggested keeping 2 local mirror copies > of the entire repository to accomplish this (with associated > config changes and manual package copying) but that seems like > a horrible amount of overhead just to make a tool work predictably. > > Couldn''t something like subversion be put under the covers to > allow atomic commits of all dependent packages at once into > the repository and allow upgrades (or downgrades) to tags or > timestamps? This seems like a job that needs exactly the set > of functions provided by a revision control package. >If you required the packages to be in a SVN/CVS repository, that''s quite an extra load on the server just to be a package mirror, so many (all?) of the freelly donated mirrors would stop doing it for free. I use a local repository and find it to be not only more reliable (I control exactly what is in it) but also much easier to work with. I can add my own packages and it is MUCH faster than even the fastest of nearby mirrors. I think that you ask for too much from the mirrors/distributions. Having people add in code is something that you can get shared freely, there is no large cost to sharing code. Adding in repositories/mirrors that have lots of extra benefits like this which require actual non-trivial costs (disk space, revision system overhead) - then, in my mind, you are moving into the area of a paid service. Greg
On Sun, 2005-03-27 at 07:05, Greg Knaddison wrote:> > > > Couldn''t something like subversion be put under the covers to > > allow atomic commits of all dependent packages at once into > > the repository and allow upgrades (or downgrades) to tags or > > timestamps? This seems like a job that needs exactly the set > > of functions provided by a revision control package. > > > > If you required the packages to be in a SVN/CVS repository, that''s > quite an extra load on the server just to be a package mirror, so many > (all?) of the freelly donated mirrors would stop doing it for free.That''s a good point - I guess all the work should be done on the client side.> I > use a local repository and find it to be not only more reliable (I > control exactly what is in it) but also much easier to work with.How do you deal with updating your mirror when the parent is also being updated and is in an inconsistent state? Do you keep two local copies so you can overlap testing new versions with installs and updates of the tested versions?> I > can add my own packages and it is MUCH faster than even the fastest of > nearby mirrors.You can add additional separate repositories for non-standard contents, and pulling the content through a caching proxy takes care of keeping a copy of what you need nearby. If you have machines in multiple locations you probably don''t want to maintain local mirrors for all of them.> I think that you ask for too much from the mirrors/distributions. > Having people add in code is something that you can get shared freely, > there is no large cost to sharing code.I''m just asking for consistent and predictable results, and hoping that the coders would like to provide that.> Adding in > repositories/mirrors that have lots of extra benefits like this which > require actual non-trivial costs (disk space, revision system > overhead) - then, in my mind, you are moving into the area of a paid > service.Perhaps, but I''ve been amazed so far at what people are doing for free and was hoping that the remaining problems were just oversights that grew out of trying to copy the apt system and applying piecemeal patches to fix the things it omits. The reason I mentioned subversion is that it is at least a 2nd generation revision control system that is designed around the issues that need to be resolved. There could be a more mirror-friendly way to do it, although I can''t think of one off the top of my head that will fix the inconsistent repository issue if you can''t control the order of file transfers among the mirrors. Does anyone know how the source-based gentoo system handles the repositories? -- Les Mikesell les@futuresource.com
On Sat, 26 Mar 2005 10:18:52 -0700, Collins Richey <crichey@gmail.com> wrote:> Has anyone had good/bad experiences with smart? Looks like the ideal > way to maintain your system at first glance.Is this a different smart than the one used to monitor your hard drives? Francois
On Sun, 27 Mar 2005 17:20:33 -0800, Francois Caen <frcaen@gmail.com> wrote:> On Sat, 26 Mar 2005 10:18:52 -0700, Collins Richey <crichey@gmail.com> wrote: > > Has anyone had good/bad experiences with smart? Looks like the ideal > > way to maintain your system at first glance. > > Is this a different smart than the one used to monitor your hard drives?Yes, indeed. It''s a software package management tool, similar to yum, apt, etc. -- Collins When I saw the Iraqi people voting three weeks ago, 8 million of them, it was the start of a new Arab world.... The Berlin Wall has fallen. - Lebanese Druze leader Walid Jumblatt