From: Robert J. C. <rj...@gm...> - 2013-02-26 00:33:00
|
All, I thought to check up on misterhouse again recently and was interested to see all the activity! I was also interested to see that there is an active GIT repository for it... Something I've not seen mention of, though, is packaging; specifically, packaging for Debian/Ubuntu. Is anyone still working on something for that? -- Robert J. Clay rj...@gm... ja...@ro... |
From: Marc M. <ma...@me...> - 2013-02-26 20:44:31
|
On Mon, Feb 25, 2013 at 07:32:39PM -0500, Robert J. Clay wrote: > All, > > I thought to check up on misterhouse again recently and was > interested to see all the activity! I was also interested to see that > there is an active GIT repository for it... > > Something I've not seen mention of, though, is packaging; > specifically, packaging for Debian/Ubuntu. Is anyone still working > on something for that? I don't think anyone is. To be fair, because there isn't any stable release per se, and the insteon code, used by many, is still actively being worked on, it would be hard to know what to package. For now, using git top of tree is by far the best option. If you'd like to start a package, you could start with the current code and submit an intent to package to debian, I assume it would take a while to get the package right, so there is no reason to wait :) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Eloy P. <pe...@ch...> - 2013-02-26 20:56:26
|
On 02/26/2013 03:43 PM, Marc MERLIN wrote: > On Mon, Feb 25, 2013 at 07:32:39PM -0500, Robert J. Clay wrote: >> All, >> >> I thought to check up on misterhouse again recently and was >> interested to see all the activity! I was also interested to see that >> there is an active GIT repository for it... >> >> Something I've not seen mention of, though, is packaging; >> specifically, packaging for Debian/Ubuntu. Is anyone still working >> on something for that? > > I don't think anyone is. > > To be fair, because there isn't any stable release per se, and the insteon > code, used by many, is still actively being worked on, it would be hard to > know what to package. > For now, using git top of tree is by far the best option. > > If you'd like to start a package, you could start with the current code and > submit an intent to package to debian, I assume it would take a while to get > the package right, so there is no reason to wait :) To add to this -- I am a Debian diehard user, and given the choice of installing something from source or from a .deb I will always choose the .deb because that keeps "filesystem pollution" to a minimum. However, installing MisterHouse from source is not too bad at all -- you just checkout the git top of free and run that, and updating is just a matter of "git pull" followed by a MH restart. It's easier than the typical C or C++ project that needs to be recompiled and rebuilt. In addition, all the required Perl modules are part of Debian (I don't think I had to install any Perl modules from CPAN) and can be installed via the regular "apt-get install libperl-xxxx". But yes, at some point in the future it would be nice to be able to do a simple "apt-get install misterhouse". That would be the easiest way to get MH up and running for first-time users. But as Marc says, right now things are too much influx to start thinking about packaging efforts. Cheers, Eloy Paris.- |
From: Marc M. <ma...@me...> - 2013-02-26 22:32:53
|
On Tue, Feb 26, 2013 at 03:55:29PM -0500, Eloy Paris wrote: > To add to this -- I am a Debian diehard user, and given the choice of > installing something from source or from a .deb I will always choose the > .deb because that keeps "filesystem pollution" to a minimum. However, The main reason why I wouldn't care for a deb for mh is that there is no filesystem polution, because there is no make install, and you just run mh from its source directory. Given that, having a deb and being all FHS compliant would only make thing more complicated IMO. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Eloy P. <pe...@ch...> - 2013-02-26 22:34:27
|
On 02/26/2013 05:31 PM, Marc MERLIN wrote: > On Tue, Feb 26, 2013 at 03:55:29PM -0500, Eloy Paris wrote: >> To add to this -- I am a Debian diehard user, and given the choice of >> installing something from source or from a .deb I will always choose the >> .deb because that keeps "filesystem pollution" to a minimum. However, > > The main reason why I wouldn't care for a deb for mh is that there is no > filesystem polution, because there is no make install, and you just run mh > from its source directory. Yes, that's true; good point. Eloy.- > Given that, having a deb and being all FHS compliant would only make thing > more complicated IMO. > > Marc > |
From: Robert J. C. <rj...@gm...> - 2013-02-28 00:29:46
|
On Tue, Feb 26, 2013 at 5:31 PM, Marc MERLIN <ma...@me...> wrote: > The main reason why I wouldn't care for a deb for mh is that there is no > filesystem polution, because there is no make install, and you just run > mh from its source directory. Doesn't it maintain state for itself somehow? Configuration? > Given that, having a deb and being all FHS compliant would only make > thing more complicated IMO. More complicated for whom? The packager or the user of the package?<g> In any case, that's part of what I'll be looking at... -- Robert J. Clay rj...@gm... |
From: Robert J. C. <rj...@gm...> - 2013-02-28 00:16:52
|
On Tue, Feb 26, 2013 at 3:55 PM, Eloy Paris <pe...@ch...> wrote: > On 02/26/2013 03:43 PM, Marc MERLIN wrote: > However, installing MisterHouse from source is not too bad at all I'll often do both when I'm in situation like this; maintain an install using whatever is the current method for the app, and maintain one done by the debian packaging being worked on. > -- you just > checkout the git top of free and run that, and updating is just a matter > of "git pull" followed by a MH restart. It's easier than the typical C > or C++ project that needs to be recompiled and rebuilt. What about that 'configure' step I recall mention of in the installation instructions I was reading online? > In addition, all > the required Perl modules are part of Debian (I don't think I had to > install any Perl modules from CPAN) and can be installed via the regular > "apt-get install libperl-xxxx". That will be another thing I need to review, so I'm glad to hear it...<g> (I'll need to review which ones are required, recommended, or suggested...) Note, btw, that if there are Perl Modules needed for MH that are not yet in Debian; I'm a member of the Debian Perl Team, so I can help with that. -- Robert J. Clay rj...@gm... |
From: Marc M. <ma...@me...> - 2013-02-28 02:03:10
|
On Wed, Feb 27, 2013 at 07:15:27PM -0500, Robert J. Clay wrote: > > checkout the git top of free and run that, and updating is just a matter > > of "git pull" followed by a MH restart. It's easier than the typical C > > or C++ project that needs to be recompiled and rebuilt. > > What about that 'configure' step I recall mention of in the > installation instructions I was reading online? Actually it would be useful to have a debian package called misterhouse-deps that simply installs all the dependencies needed by misterhouse. That's by far the most bang for the buck. > Note, btw, that if there are Perl Modules needed for MH that are > not yet in Debian; I'm a member of the Debian Perl Team, so I can > help with that. That would be good to add them then, and have an easy way to install with apt-get install misterhouse-deps On Wed, Feb 27, 2013 at 07:28:54PM -0500, Robert J. Clay wrote: > > The main reason why I wouldn't care for a deb for mh is that there is no > > filesystem polution, because there is no make install, and you just run > > mh from its source directory. > > Doesn't it maintain state for itself somehow? Configuration? It's in ~mh/data > > Given that, having a deb and being all FHS compliant would only make > > thing more complicated IMO. > > More complicated for whom? The packager or the user of the > package?<g> In any case, that's part of what I'll be looking at... Both. Making a full debian package of mh will likely force you to split mh in multiple directories between /usr, /var, /var/cache, and other, making the tree very different from what everyone else has. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Robert J. C. <rj...@gm...> - 2013-03-03 12:14:39
|
Marc, On Wed, Feb 27, 2013 at 9:00 PM, Marc MERLIN <ma...@me...> wrote: > On Wed, Feb 27, 2013 at 07:15:27PM -0500, Robert J. Clay wrote: > Actually it would be useful to have a debian package called > misterhouse-deps that simply installs all the dependencies needed by > misterhouse. .... I don't see the point of maintaining something like that, separately from a package that does a MisterHouse installation; still, once I have a working package, it would be easy enough to branch that and create something like a 'misterhouse-deps' package from it. However; I'd think it'd be useful in more situations to maintain a file or files in the source that contains a listing of the required & other Perl modules (which, btw, if there's already something like that, I've not found it yet...) plus scripts to install them for particular OS's and/or environments. I originally thought It'd be useful to split up the 'binary' (i.e., installation) packages for MisterHouse; in which case having something like a misterhouse-common package could be useful, and that package could have the dependencies. I'm not so sure now that having such separate installation packages (except possibly for things like docs, or plugins if MisterHouse goes in that direction) would actually be useful, especially given what I've found so far that isn't necessary for a Debian package (Like the lib/site* directories ...), which means that a misterhouse_M.NNN-1_all.deb package archive (and even the source archive) may end up not being as large I was thinking it would need to be... -- Robert J. Clay rj...@gm... |
From: Robert J. C. <rj...@gm...> - 2013-03-03 12:43:16
|
Marc, On Wed, Feb 27, 2013 at 9:00 PM, Marc MERLIN <ma...@me...> wrote: > On Wed, Feb 27, 2013 at 07:28:54PM -0500, Robert J. Clay wrote: >> > The main reason why I wouldn't care for a deb for mh is that there is no >> > filesystem polution, because there is no make install, and you just run >> > mh from its source directory. >> >> Doesn't it maintain state for itself somehow? Configuration? > > It's in ~mh/data And isn't that "filesystem polution", once MisterHouse is operational? >> > Given that, having a deb and being all FHS compliant would only make >> > thing more complicated IMO. >> >> More complicated for whom? The packager or the user of the >> package?<g> In any case, that's part of what I'll be looking at... > > Both. Making a full debian package of mh will likely force you to split > mh in multiple directories between /usr, /var, /var/cache, and other, If I understand correctly; once MisterHouse is told where everything is, it doesn't care...<g> (In fact, that's one of the things that drew me back into taking a look at MisterHouse again; how customizable it looks to be...) > making the tree very different from what everyone else has. But not different from what people that already use Debian/Ubuntu/etc are used to and familiar with... (And those are the target for a debian package, after all...) -- Robert J. Clay rj...@gm... |
From: Robert J. C. <rj...@gm...> - 2013-03-12 15:33:39
|
Marc, On Mon, Mar 11, 2013 at 10:10 AM, Marc MERLIN <ma...@me...> wrote: > On Mon, Mar 11, 2013 at 07:56:09AM -0400, Robert J. Clay wrote: >> > If you're doing do a debian package, please make a real one. >> >> Now, there's a rather provocative comment... > > It was a short way to make sure we agreed that an ubuntu only > package was not a debian package. Well, no it's not and since all of my systems are at least Debian hosted (I run other OS's in VMs, LXC, etc...) that's not the type of packages I work on. My official packages only get into Ubuntu by way of Debian, just like any other distro that has Debian as upstream. Unofficial packages I do may be directed to Ubuntu but at least the initial dev work is on Debian since that is what I work in. >> > There is no reason to use upstart for this, over a normal initscript >> >> Why do you assume that I would have the package doing so? > > If that was not your plan, I misread and please accept my apologies > for the mistake. And please accept mine, as I could have been clearer that my interest was more in general than any specific plans for the MisterHouse package. (Although I do think having an example upstart init script in the MisterHouse repository would be a good thing, just like I plan to get an updated one for Debian in.) -- Robert J. Clay rj...@gm... |
From: Marc M. <ma...@me...> - 2013-03-12 15:54:39
|
On Tue, Mar 12, 2013 at 11:33:32AM -0400, Robert J. Clay wrote: > Marc, > > On Mon, Mar 11, 2013 at 10:10 AM, Marc MERLIN <ma...@me...> wrote: > > On Mon, Mar 11, 2013 at 07:56:09AM -0400, Robert J. Clay wrote: > >> > If you're doing do a debian package, please make a real one. > >> > >> Now, there's a rather provocative comment... > > > > It was a short way to make sure we agreed that an ubuntu only > > package was not a debian package. > > Well, no it's not and since all of my systems are at least Debian > hosted (I run other OS's in VMs, LXC, etc...) that's not the type of > packages I work on. My official packages only get into Ubuntu by way > of Debian, just like any other distro that has Debian as upstream. > Unofficial packages I do may be directed to Ubuntu but at least the > initial dev work is on Debian since that is what I work in. Great to hear :) Also, for anyone following, it's actually possible to make a package that contains initscripts for both sysv and upstart, but the problem packages I looked at in the past were unfortunately upstart only. > And please accept mine, as I could have been clearer that my > interest was more in general than any specific plans for the > MisterHouse package. (Although I do think having an example upstart > init script in the MisterHouse repository would be a good thing, just > like I plan to get an updated one for Debian in.) There is indeed nothing wrong with also supporting upstart or systemd as long as the 2 or 3 initscripts stay in sync and all work. Cheers, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Marc M. <ma...@me...> - 2013-03-03 15:04:57
|
On Sun, Mar 03, 2013 at 07:14:31AM -0500, Robert J. Clay wrote: > I originally thought It'd be useful to split up the 'binary' (i.e., > installation) packages for MisterHouse; in which case having > something like a misterhouse-common package could be useful, and that > package could have the dependencies. I'm not so sure now that having > such separate installation packages (except possibly for things like > docs, or plugins if MisterHouse goes in that direction) would actually > be useful, especially given what I've found so far that isn't > necessary for a Debian package (Like the lib/site* directories ...), > which means that a misterhouse_M.NNN-1_all.deb package archive (and > even the source archive) may end up not being as large I was thinking > it would need to be... I'm honestly not up to date on debian packaging rules, so I'll leave that up to you. But yes, if it's possible to have some misterhouse-deps shell package, I think it would help a fair amount of people, even though it's not a typical thing for debian to do. On Sun, Mar 03, 2013 at 07:43:07AM -0500, Robert J. Clay wrote: > >> Doesn't it maintain state for itself somehow? Configuration? > > > > It's in ~mh/data > > And isn't that "filesystem polution", once MisterHouse is operational? Not if it's all under a same tree. Software that can be deleted with rm -rf ~mh isn't poluting :) (ok, technically there is a 2nd step which is removing the passwd file entry if any) > > Both. Making a full debian package of mh will likely force you to split > > mh in multiple directories between /usr, /var, /var/cache, and other, > > If I understand correctly; once MisterHouse is told where > everything is, it doesn't care...<g> (In fact, that's one of the > things that drew me back into taking a look at MisterHouse again; how > customizable it looks to be...) Yes, it's very customizable. > > making the tree very different from what everyone else has. > > But not different from what people that already use > Debian/Ubuntu/etc are used to and familiar with... (And those are > the target for a debian package, after all...) In my experience, that will make helping users worse, not better. People will tell you "please edit mh/data/triggers.current" or "you should remove mh/code/triggers.mhp" and you'll be one of the few people with the file totally elsewhere on your filesystem. It's not fatal, but it makes things a bit harder. I know, I've had to do deal with this with other packages that were debianized, and had to use find and other tools to find where the damn file I was looking for had ended up. Maybe it's the price to pay for a ready to install package, and I'm not saying your work is not useful, but just explaining my small beef :) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Robert J. C. <rj...@gm...> - 2013-03-04 23:44:20
|
Marc, On Sun, Mar 3, 2013 at 10:04 AM, Marc MERLIN <ma...@me...> wrote: > On Sun, Mar 03, 2013 at 07:14:31AM -0500, Robert J. Clay wrote: >> I originally thought It'd be useful to split up the 'binary' (i.e., >> installation) packages for MisterHouse; in which case having >> something like a misterhouse-common package could be useful, and that >> package could have the dependencies. > But yes, if it's possible to have some misterhouse-deps shell package, I > think it would help a fair amount of people, even though it's not a typical > thing for debian to do. I'll take a look at the possibility but think it unlikely that such a package would be acceptable by itself in Debian or Ubuntu. And, thinking about it, using something like a misterhouse-common package wouldn't work because something like that is also going to be installing directories as necessary, so that wouldn't be useful for installing it manually. Note, btw, that such a package only needs to be in a package archive for the package installations to work... OTOH, I noticed that there is a directory (code/support) that could be used to keep scripts that could do such package installs directly (using apt-get or aptitude), which would always work; there would still be the possible issue of maintaining the package list, of course. -- Robert J. Clay rj...@gm... |
From: Michael S. <mi...@st...> - 2013-03-03 15:38:19
|
On Mar 03, 2013 6:43 AM Robert wrote, > > On Wed, Feb 27, 2013 at 9:00 PM, Marc MERLIN <ma...@me...> wrote: > > On Wed, Feb 27, 2013 at 07:28:54PM -0500, Robert J. Clay wrote: > >> > The main reason why I wouldn't care for a deb for mh is that there is no > >> > filesystem polution, because there is no make install, and you just run > >> > mh from its source directory. > >> > >> Doesn't it maintain state for itself somehow? Configuration? > > > > It's in ~mh/data > > And isn't that "filesystem polution", once MisterHouse is operational? I run Debian and loosely understand FHS but I can't claim to know what Debian package administrators consider acceptable. On my system I place the MH distribution into /usr/lib/mh.version and logically link that to /usr/lib/mh. I then place the user files including the code and data directories in /var/mh. A mh user is then created and given the /var/mh home directory. So logging in as mh gives the familiar ~/mh.private.ini, ~/code/..., ~/data/logs, etc. I know this isn't 100% in the spirit of Debian FHS but I think it might be close enough and still retain some semblance of supportability. What do you all think about this two location approach? Sincerely, Michael |
From: Robert J. C. <rj...@gm...> - 2013-03-05 00:11:15
|
On Sun, Mar 3, 2013 at 10:38 AM, Michael Stovenour <mi...@st...> wrote: > On Mar 03, 2013 6:43 AM Robert wrote, >> >> On Wed, Feb 27, 2013 at 9:00 PM, Marc MERLIN <ma...@me...> wrote: >> > On Wed, Feb 27, 2013 at 07:28:54PM -0500, Robert J. Clay wrote: >> >> > The main reason why I wouldn't care for a deb for mh is that there is no >> >> > filesystem polution, because there is no make install, and you just run >> >> > mh from its source directory. >> >> >> >> Doesn't it maintain state for itself somehow? Configuration? >> > >> > It's in ~mh/data >> >> And isn't that "filesystem polution", once MisterHouse is operational? > > I run Debian and loosely understand FHS but I can't claim to know what Debian package > administrators consider acceptable. On my system I place the MH distribution into > /usr/lib/mh.version and logically link that to /usr/lib/mh. This is a manual install? You should perhaps consider /usr/local/lib/mh instead of /usr/lib/mh: /usr/local is under the control of the local admin while /usr/lib is controlled by the package manager. I checked and didn't happen to find any file or directory conflicts but that doesn't mean there couldn't be something later. > I then place the user files > including the code and data directories in /var/mh. A mh user is then created and given > the /var/mh home directory. You might consider using '/var/local/mh', as /var/local/ also wouldn't be affected by the package manager. > So logging in as mh gives the familiar ~/mh.private.ini, ~/code/..., ~/data/logs, etc. I usually set the home directory for system users in the same kind of way. -- Robert J. Clay rj...@gm... |
From: Robert J. C. <rj...@gm...> - 2013-03-05 00:28:45
|
On Sun, Mar 3, 2013 at 10:38 AM, Michael Stovenour <mi...@st...> wrote: > What do > you all think about this two location approach? Besides that I think that you'd be better off using /usr/local/ & /var/local, I think it's a good way to do it. What I'm thinking currently is that the package installation will use: /usr/share/misterhouse: /usr/share is for arch independent files and it seems so far that most of mh/bin & mh/code can go there. I do see, however, that there are some arch dependent files in there (like viavoice_server, which I'll ask about in another thread), so there may be a need for a /usr/lib/misterhouse directory as well. /usr/share/doc/misterhouse: basic package documentation /usr/share/doc/misterhouse-doc: html documentation etc, and examples. (currently that will be installed using a separate 'misterhouse-doc' package. /var/lib/misterhouse: "mh/data", basically.. I'll know more when I have more experience with mh...<g> /etc/misterhouse: ini files, etc. -- Robert J. Clay rj...@gm... |
From: Eloy P. <pe...@ch...> - 2013-03-03 17:56:26
|
On 03/03/2013 10:38 AM, Michael Stovenour wrote: > On Mar 03, 2013 6:43 AM Robert wrote, >> >> On Wed, Feb 27, 2013 at 9:00 PM, Marc MERLIN <ma...@me...> wrote: >>> On Wed, Feb 27, 2013 at 07:28:54PM -0500, Robert J. Clay wrote: >>>>> The main reason why I wouldn't care for a deb for mh is that there is no >>>>> filesystem polution, because there is no make install, and you just run >>>>> mh from its source directory. >>>> >>>> Doesn't it maintain state for itself somehow? Configuration? >>> >>> It's in ~mh/data >> >> And isn't that "filesystem polution", once MisterHouse is operational? > > I run Debian and loosely understand FHS but I can't claim to know what Debian package > administrators consider acceptable. On my system I place the MH distribution into > /usr/lib/mh.version and logically link that to /usr/lib/mh. I then place the user files > including the code and data directories in /var/mh. A mh user is then created and given > the /var/mh home directory. So logging in as mh gives the familiar ~/mh.private.ini, > ~/code/..., ~/data/logs, etc. I know this isn't 100% in the spirit of Debian FHS but I > think it might be close enough and still retain some semblance of supportability. What do > you all think about this two location approach? I also run Debian (well, Ubuntu server, but that is pretty close) and use the same approach. The only difference is that I put the MH installation under /opt (using a symlink /opt/mh -> /opt/mh-gitmaster, -> /opt/mh-test, etc.) and the user that MisterHouse runs as has its home directory under /home, i.e. /home/mrhouse. I go to extreme lengths by configuring ~/mh.private.ini to make sure that any data generated by MisterHouse is confined to ~mrhouse, so /opt/mh can be read-only and I don't have to worry about migrating data when I switch to a different MH version or branch. The only thing that lives outside these two locations is the MH init (upstart) script /etc/init/mh.conf. Cheers, Eloy Paris.- |
From: Vargster <var...@gm...> - 2013-03-04 19:42:38
|
Yes, I'm confused by this 'pollution' too. I use the scheme that's in the wiki, which I think originally came from Neil Cherry. /opt/misterhouse holds everything there's /opt/misterhouse/code for the user code /opt/misterhouse/data for all the data /opt/misterhouse/data/logs for the logs /opt/misterhouse/rrd for rrd stuff /opt/misterhouse/mh for the current version of the production code /opt/misterhouse/mh-1 for the previous version of the code. Should I need to revert, just stop mh, rename the directory and restart. Job done. As Eloy said the only file to live outside the /opt/misterhouse folder is the upstart script to run mh on boot. Pollution is 1 file and 1 directory. There is a mh user, but I don't use the home folder for anything, it's all in /opt/misterhouse. All in all Neil's scheme seems a lot cleaner than the others outlined above. Lee On Sun, Mar 3, 2013 at 5:55 PM, Eloy Paris <pe...@ch...> wrote: > On 03/03/2013 10:38 AM, Michael Stovenour wrote: > > > On Mar 03, 2013 6:43 AM Robert wrote, > >> > >> On Wed, Feb 27, 2013 at 9:00 PM, Marc MERLIN <ma...@me...> > wrote: > >>> On Wed, Feb 27, 2013 at 07:28:54PM -0500, Robert J. Clay wrote: > >>>>> The main reason why I wouldn't care for a deb for mh is that there > is no > >>>>> filesystem polution, because there is no make install, and you just > run > >>>>> mh from its source directory. > >>>> > >>>> Doesn't it maintain state for itself somehow? Configuration? > >>> > >>> It's in ~mh/data > >> > >> And isn't that "filesystem polution", once MisterHouse is > operational? > > > > I run Debian and loosely understand FHS but I can't claim to know what > Debian package > > administrators consider acceptable. On my system I place the MH > distribution into > > /usr/lib/mh.version and logically link that to /usr/lib/mh. I then > place the user files > > including the code and data directories in /var/mh. A mh user is then > created and given > > the /var/mh home directory. So logging in as mh gives the familiar > ~/mh.private.ini, > > ~/code/..., ~/data/logs, etc. I know this isn't 100% in the spirit of > Debian FHS but I > > think it might be close enough and still retain some semblance of > supportability. What do > > you all think about this two location approach? > > I also run Debian (well, Ubuntu server, but that is pretty close) and > use the same approach. The only difference is that I put the MH > installation under /opt (using a symlink /opt/mh -> /opt/mh-gitmaster, > -> /opt/mh-test, etc.) and the user that MisterHouse runs as has its > home directory under /home, i.e. /home/mrhouse. > > I go to extreme lengths by configuring ~/mh.private.ini to make sure > that any data generated by MisterHouse is confined to ~mrhouse, so > /opt/mh can be read-only and I don't have to worry about migrating data > when I switch to a different MH version or branch. > > The only thing that lives outside these two locations is the MH init > (upstart) script /etc/init/mh.conf. > > Cheers, > > Eloy Paris.- > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Robert J. C. <rj...@gm...> - 2013-03-05 00:00:26
|
On Sun, Mar 3, 2013 at 10:04 AM, Marc MERLIN <ma...@me...> wrote: > On Sun, Mar 03, 2013 at 07:43:07AM -0500, Robert J. Clay wrote: >> >> Doesn't it maintain state for itself somehow? Configuration? >> > >> > It's in ~mh/data >> >> And isn't that "filesystem polution", once MisterHouse is operational? > > Not if it's all under a same tree. > Software that can be deleted with rm -rf ~mh isn't poluting :) Ah, I see; that's not quite what I was thinking of, being more specifically related to upgrade issues within the install than that intallation affecting other parts of the file system outside of the install... -- Robert J. Clay rj...@gm... |
From: Marc M. <ma...@me...> - 2013-03-05 00:16:47
|
On Mon, Mar 04, 2013 at 07:00:19PM -0500, Robert J. Clay wrote: > > Not if it's all under a same tree. > > Software that can be deleted with rm -rf ~mh isn't poluting :) > > Ah, I see; that's not quite what I was thinking of, being more > specifically related to upgrade issues within the install than that I have never had an update issue with mh that a package manager would have helped with, again mostly because there is no make install that craps all over your filesysteem :) svn update or git update, restart mh, done. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Robert J. C. <rj...@gm...> - 2013-03-12 15:13:23
|
Marc, On Mon, Mar 4, 2013 at 7:16 PM, Marc MERLIN <ma...@me...> wrote: > On Mon, Mar 04, 2013 at 07:00:19PM -0500, Robert J. Clay wrote: >> > Not if it's all under a same tree. >> > Software that can be deleted with rm -rf ~mh isn't poluting :) >> >> Ah, I see; that's not quite what I was thinking of, being more >> specifically related to upgrade issues within the install than that > > I have never had an update issue with mh that a package manager > would have helped with, again mostly because there is no make > install that craps all over your filesysteem :) But for the Debian packaging, it is something I need to keep in mind, even if it doesn't actually end up as something I need to worry about. > svn update or git update, restart mh, done. I'll be testing it that way as well, to get familiar with it. -- Robert J. Clay rj...@gm... ja...@ro... |
From: Robert J. C. <rj...@gm...> - 2013-03-05 00:39:01
|
On Sun, Mar 3, 2013 at 12:55 PM, Eloy Paris <pe...@ch...> wrote: > The only thing that lives outside these two locations is the MH init > (upstart) script /etc/init/mh.conf. Which I would be most interested in taking a look at, if that's possible; I'm not yet familiar with upstart as yet... -- Robert J. Clay rj...@gm... |
From: Robert J. C. <rj...@gm...> - 2013-03-05 00:43:44
|
On Mon, Mar 4, 2013 at 7:16 PM, Marc MERLIN <ma...@me...> wrote: > On Mon, Mar 04, 2013 at 07:00:19PM -0500, Robert J. Clay wrote: >> > Not if it's all under a same tree. >> > Software that can be deleted with rm -rf ~mh isn't poluting :) >> >> Ah, I see; that's not quite what I was thinking of, being more >> specifically related to upgrade issues within the install than that > > I have never had an update issue with mh that a package manager would have > helped with, again mostly because there is no make install that craps all > over your filesysteem :) > > svn update or git update, restart mh, done. My concern is for things like files that MH uses during it's operation, files it generates, files that the admin may have created, etc. Perhaps that's not an issue with misterhouse, but then I'm not familiar with it as yet...<g> -- Robert J. Clay rj...@gm... -- Robert J. Clay rj...@gm... |
From: Eloy P. <pe...@ch...> - 2013-03-05 03:51:12
Attachments:
mh.conf
|
On 03/04/2013 07:38 PM, Robert J. Clay wrote: > On Sun, Mar 3, 2013 at 12:55 PM, Eloy Paris <pe...@ch...> wrote: > >> The only thing that lives outside these two locations is the MH init >> (upstart) script /etc/init/mh.conf. > > Which I would be most interested in taking a look at, if that's > possible; I'm not yet familiar with upstart as yet... My /etc/init/mh.conf is attached. MH starts on a "screen" session so I can attach to it to read messages sent to standard output or standard error by running "screen -r <user MH runs as>/". Cheers, Eloy Paris.- |