Re: [Leaf-devel] CVS structure ??? [LONG]
Mike Noyes schrieb: [snip] What happens when I decide that /usr/sbin/ntp_setup actually belongs /usr/bin/ntp_setup? Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp? Clearly, cvs cannot know my intent, in this regard. When committing a directory change, under this scenario, how should it be done? If we had shell access to the repository, we would hand edit the structure change. SF doesn't allow us shell access to the cvs server, so we need to open SF support requests to make changes like this. ref. CVS repository clean-up requests https://sourceforge.net/tracker/?group_id=1atid=21 I don't think it is a good idea to make a change like this. If someone wants to retrieve an older version, it does not work because the file he needs is not available anymore. It is better to create the new file in CVS and pin the release/version tag to the new file and not to the old file. [snip] -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 03:56, Manfred Schuler wrote:
Mike Noyes schrieb:
If we had shell access to the repository, we would hand edit the
structure change. SF doesn't allow us shell access to the cvs server, so
we need to open SF support requests to make changes like this.
ref. CVS repository clean-up requests
https://sourceforge.net/tracker/?group_id=1atid=21
I don't think it is a good idea to make a change like this.
If someone wants to retrieve an older version, it does not work
because the file he needs is not available anymore.
It is better to create the new file in CVS and pin the
release/version tag to the new file and not to the old file.
Manfred,
That has not been my experience. When the SF staff moves/renames files
on the SF cvs server they maintain the cvs structure. Talk with Jacob
Moorman, Quality of Service Manager ('moorman' on SourceForge.net,
'moorman' on SlashNET IRC) to verify this if you like.
--
Mike Noyes [EMAIL PROTECTED]
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/
---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases more
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Mike,
I did _NOT_ at all want to criticize the staff at SF.
I know about them only what I see on the list, so I'm
not in a position to judge how they do their job.
I think I didn't express clearly what I mean.
It is meant as a principle when working on large projects:
_NEVER_ change anything that is correctly checked in
I will give you an example of what I mean:
In version 1.0 of package xxx you have 2 script files:
scripta and scriptb
One line in scripta is
source scriptb
Later you decide scriptb is not a good name and you change the name
to scriptc and the line in scripta to:
source scriptc
The version 1.1 of the package xxx consists now of the files
scripta and scriptc.
Now you rename scriptb in your CVS tree to scriptc.
A user who wants to checkout version 1.0 gets a problem because
scripta requires scriptb, but someone who dosen't know about
the rename, doesn't know where to get scriptb.
Even when the label is moved with the files, you get
scripta and scriptc on checkout, but the package won't work
because of the wrong filename.
You see, when you rename files in CVS, you get nonfunctional old
versions.
Mike Noyes schrieb:
On Thu, 2002-07-11 at 03:56, Manfred Schuler wrote:
Mike Noyes schrieb:
If we had shell access to the repository, we would hand edit the
structure change. SF doesn't allow us shell access to the cvs server, so
we need to open SF support requests to make changes like this.
ref. CVS repository clean-up requests
https://sourceforge.net/tracker/?group_id=1atid=21
I don't think it is a good idea to make a change like this.
If someone wants to retrieve an older version, it does not work
because the file he needs is not available anymore.
It is better to create the new file in CVS and pin the
release/version tag to the new file and not to the old file.
Manfred,
That has not been my experience. When the SF staff moves/renames files
on the SF cvs server they maintain the cvs structure. Talk with Jacob
Moorman, Quality of Service Manager ('moorman' on SourceForge.net,
'moorman' on SlashNET IRC) to verify this if you like.
--
Mike Noyes [EMAIL PROTECTED]
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/
---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases more
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
--
Manfred Schuler
E_Mail: mailto:[EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases more
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: Mike, I did _NOT_ at all want to criticize the staff at SF. I know about them only what I see on the list, so I'm not in a position to judge how they do their job. Manfred, I apologize for the tone of my last message. It was inappropriate. Sorry. I think I didn't express clearly what I mean. It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in I will give you an example of what I mean: In version 1.0 of package xxx you have 2 script files: scripta and scriptb One line in scripta is source scriptb Later you decide scriptb is not a good name and you change the name to scriptc and the line in scripta to: source scriptc The version 1.1 of the package xxx consists now of the files scripta and scriptc. Now you rename scriptb in your CVS tree to scriptc. A user who wants to checkout version 1.0 gets a problem because scripta requires scriptb, but someone who dosen't know about the rename, doesn't know where to get scriptb. Even when the label is moved with the files, you get scripta and scriptc on checkout, but the package won't work because of the wrong filename. You see, when you rename files in CVS, you get nonfunctional old versions. Ah, now I see. :-) I hadn't considered this sequence of actions. I believe interdependent files that require movement/renaming are candidates for branches. Would branching the sample above be an appropriate course of action? -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: I think I didn't express clearly what I mean. It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in I will give you an example of what I mean: In version 1.0 of package xxx you have 2 script files: scripta and scriptb One line in scripta is source scriptb Later you decide scriptb is not a good name and you change the name to scriptc and the line in scripta to: source scriptc The version 1.1 of the package xxx consists now of the files scripta and scriptc. Now you rename scriptb in your CVS tree to scriptc. Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. $ cp scriptb scriptc $ cvs add scriptc $ cvs ci -m added scriptc old filename was scriptb scriptc $ rm scriptb $ cvs remove scriptb $ cvs ci -m removed scriptb new filename is scriptc scriptb I believe this will leave the repository in a correct state, and solve the older version retrieval problem. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 07:51, Mike Noyes wrote: Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. Here is a small but significant addition to this sequence. It will allow retrieval of the tree in its 1.0 state. $ cvs -q tag R_1_0 $ cp scriptb scriptc $ cvs add scriptc $ cvs ci -m added scriptc old filename was scriptb scriptc $ rm scriptb $ cvs remove scriptb $ cvs ci -m removed scriptb new filename is scriptc scriptb I believe this will leave the repository in a correct state, and solve the older version retrieval problem. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in Manfred, Incorrectly checked in files/directories are candidates for SF staff cvs repository clean-up support requests (SR). I believe there are other instances where SF cvs SRs are appropriate too. Please take a look at our old SF SRs. In which cases should I have used standard cvs commands to accomplish these tasks? [ 574291 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=574291group_id=1atid=21 [ 547717 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547717group_id=1atid=21 [ 547118 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547118group_id=1atid=21 [ 525177 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=525177group_id=1atid=21 [ #513309 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=513309group_id=1atid=21 [ #503058 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=503058group_id=1atid=21 -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Mike Noyes schrieb: On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: Mike, I did _NOT_ at all want to criticize the staff at SF. I know about them only what I see on the list, so I'm not in a position to judge how they do their job. Manfred, I apologize for the tone of my last message. It was inappropriate. Sorry. No reason to apologize. I think I didn't express clearly what I mean. It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in I will give you an example of what I mean: In version 1.0 of package xxx you have 2 script files: scripta and scriptb One line in scripta is source scriptb Later you decide scriptb is not a good name and you change the name to scriptc and the line in scripta to: source scriptc The version 1.1 of the package xxx consists now of the files scripta and scriptc. Now you rename scriptb in your CVS tree to scriptc. A user who wants to checkout version 1.0 gets a problem because scripta requires scriptb, but someone who dosen't know about the rename, doesn't know where to get scriptb. Even when the label is moved with the files, you get scripta and scriptc on checkout, but the package won't work because of the wrong filename. You see, when you rename files in CVS, you get nonfunctional old versions. Ah, now I see. :-) I hadn't considered this sequence of actions. I believe interdependent files that require movement/renaming are candidates for branches. Would branching the sample above be an appropriate course of action? No need to branch. Just remove the HEAD and MAIN tags from the old file. -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Location for scripts during startup
Question:
I am looking at implementing the following sequence of events in a redesign fo the
weblet:
(this is the weblet as we are now defining it, a web application that is seperate from
the underlying sh-httpd server)
-
system starts boot
all packages finish loading
weblet runs script to gather all package conf files (/var/lib/lrpkg/*.conf files) to
generate the configuration display component in weblet (to replace the hard coded one
in the Dev Demo now)
weblet runs script to gather weblet addon package conf files
(/var/lib/lrpkg/w-xx.conf files) and to regenerate its /var/lib/lrpkg/weblet.conf
file to these addon config files
LEAF start up completes
--
Where is the appropriate location to initiate the above scripts so that they are
executed at the proper time, after all the packages have loaded?
It looks like this might be easy to find, but as this is an important point, I would
feel better getting an expert answer.
The idea here is to simplify the weblet system so that there is a small base dashboard
(much like it is now) with the ability to add new components and manage them as easily
as adding additional lrp packages.
Thanks!
Richard Amerman
áË ë^¨¥Ë)¢{(ç[É8bAzCÂ2l
©ºØ§
(v'¬q« ²j+zm§ÿí)äç¤r¿±òÞi÷^½éfj)b
b²ÒÞi÷^½éeËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?æuëÞ
RE: [Leaf-devel] Location for scripts during startup
Thanks for the feedback! From: Erich Titl [mailto:[EMAIL PROTECTED]] Sent: Thu 7/11/2002 11:37 AM It will be great to have that much autoconfiguration in the 'weblet'. Do you think it would be a big overhead to run this 'real time' e.g. when the dashboard is requested. That way even a modification on a running machine would immediately be reflected in the weblet. Actualy, the object of this particular automation is only to capture changes to the LEAF configuation as it relates to added packages of any type, including weblet addons. This functionality basicaly mirrors what lrcfg is doing (I have not looked under the hood of lrcfg, but the result is the same) to automaticly include the configuration menu's/files for any packages you add. As the process for this is to copy the package file to the media and then boot the system, this automation only needs to happen at startup. There certainly will be other forms of automation within weblet that will be realtime. Actualy, there is now. If you look at the Weblet Dev Demo (207.202.227.167) you can see that the source link at the botom of the page gives you all the source files for the weblet. This script simply gives you what it finds in a few key folders under /var/sh-www. Any files that are added are then automaticaly included. This is very simple but does ilustrate the point. As the weblet is only realy intended for one or at most just a few users, performance is of very little concern. Not that it is not something to keep in mind, just not a top priority. Richard Amerman N¬±ùÞµéX¬²'²Þu¼)äç¤#(vÀ¨x ¢bzDZ뢷¡¶ÚþØbH zG(û -æuëÞf¢)à+--æuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣù^i÷^½é
Re: [Leaf-devel] Location for scripts during startup
I am looking at implementing the following sequence of events in a redesign fo the weblet: (this is the weblet as we are now defining it, a web application that is seperate from the underlying sh-httpd server) - system starts boot Handled by syslinux... all packages finish loading ...and the filsystem is fully populated (/etc/rc?.d/* links created, busybox links created, /dev populated, etc). All this is handled by /linuxrc weblet runs script to gather all package conf files (/var/lib/lrpkg/*.conf files) to generate the configuration display component in weblet (to replace the hard coded one in the Dev Demo now) weblet runs script to gather weblet addon package conf files (/var/lib/lrpkg/w-xx.conf files) and to regenerate its /var/lib/lrpkg/weblet.conf file to these addon config files This is probably something for the init scripts to deal with (if required). LEAF start up completes -- Where is the appropriate location to initiate the above scripts so that they are executed at the proper time, after all the packages have loaded? It looks like this might be easy to find, but as this is an important point, I would feel better getting an expert answer. The idea here is to simplify the weblet system so that there is a small base dashboard (much like it is now) with the ability to add new components and manage them as easily as adding additional lrp packages. Any startup-time config should be handled by the init scripts (/etc/init.d /etc/rc?.d/), but a lot of the site content should probably be generated on the fly...this shouldn't be too CPU intensive if a proper directory structure for weblet add-on packages is created. There is a project in progress to do this already...see the Richard's e-mail and weblet demo site. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Comments inline Mike Noyes schrieb: On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in Manfred, Incorrectly checked in files/directories are candidates for SF staff cvs repository clean-up support requests (SR). I believe there are other instances where SF cvs SRs are appropriate too. Please take a look at our old SF SRs. In which cases should I have used standard cvs commands to accomplish these tasks? [ 574291 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=574291group_id=1atid=21 removing empty directories or renaming a top level directory should not impose any problem because there should not be any dependencies. [ 547717 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547717group_id=1atid=21 Removing 'x' bit should do no harm [ 547118 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547118group_id=1atid=21 Removing 'x' bit should do no harm [ 525177 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=525177group_id=1atid=21 top level directory, ok [ #513309 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=513309group_id=1atid=21 top level directory, ok [ #503058 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=503058group_id=1atid=21 Developers top level directory, should be ok -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bering RC3 build with uClibc
On Wed, 10 Jul 2002, Eric Spakman wrote: [...] Re: the value of uClibc... I think it is good that someone is doing this, but it is also good to be clear that the gain in code size comes at a potential narrowing of applicability due to incompatibility with glibc. For closed boxes, this is probably actually desirable... but one of the selling points of LEAF is its adaptability. To the extent that uClibc fails to implement features of glibc (e.g. localization), the usefulness of LEAF based on it will be necessarily limited. uClibc does have locale support (new feature). This is good to know. I don't feel it invalidates my point, though. On the other hand, most binaries compiled against a modern Glibc (2.2.x) are not compatible with the old Glibc used in LEAF (my experience, maybe I did something wrong :-). So to create binaries for LEAF I needed an old Linux distribution with Glibc2.0, for uClibc I just installed the development environment on my 'modern' distribution. Development environments for Glibc2.0 exist for 'modern' distributions. Your choice to use uClibc was simply that... a choice. Also, some variants of LEAF are already grappling with the size vs. compatibility issues of software that requires glibc2.2. glibc2.0 currently seems to have the best compatibility vs. size combination. To reiterate I think there is room for both, but the tradeoffs should be made clear to new LEAF users. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 13:17, Manfred Schuler wrote: Comments inline Manfred, Thanks for the analysis. I'm glad I don't appear to be causing problems in our repository. Mike Noyes schrieb: [ 547717 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547717group_id=1atid=21 Removing 'x' bit should do no harm I added some enforce scripts to our CVSROOT recently. Would you take a look at them and let me know if you see any problems? Thanks. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/CVSROOT/ -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Mike Noyes schrieb: On Thu, 2002-07-11 at 07:51, Mike Noyes wrote: Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. Here is a small but significant addition to this sequence. It will allow retrieval of the tree in its 1.0 state. 1$ cvs -q tag R_1_0 2$ cp scriptb scriptc 3$ cvs add scriptc 4$ cvs ci -m added scriptc old filename was scriptb scriptc 5$ rm scriptb 6$ cvs remove scriptb 7$ cvs ci -m removed scriptb new filename is scriptc scriptb [snip] I recommend to tag every release with an appropriate label. So you can retrieve any old release or verify what is released. I also recommend to tag the latest release with somthing like 'latest' for easy retrieval. I don't think this sequence will work because in line 5 you remove scriptb and in line 7 you try to checkin scriptb. I have no experience with cvs and from the man pages I could not determine if line 6 removes only the last version or all versions of scriptb. If it removes all versions you get the problem with version 0.9. I would use this sequence cvs -q tag R_1_0 cvs -f ci -m file renamed to scriptc scriptb cvs -q tag -d MAIN scriptb mv scriptb scriptc cvs add scriptc cvs ci -m file renamed from scriptb scriptc This sequence is not tested. It is just what I can read from the man pages. Maybe you need additonally this line cvs remove scriptb but as mentioned, I don't know what exactly is removed. Maybe the tag MAIN cannot be deleted, although I couldn't find it in the man page. -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Location for scripts during startup
My message may have been a bit confusing. This is the weblet Richard and this is for some changes I'm making to the weblet. The only thing that needs to be generated on startup is the collection of what packages are there, both all the genearal packages and any weblet addons. The packages are already listed for you, in /var/lib/lrpkg/packages (see the lrpkg scripts, and the SF FAQ for details on how the packaging system works). Weblet packages should also be easy to identify (maybe with a packages file, similar to the above file, or maybe by directory structure). I know it would be no big deal to do this dynamicaly in the site, but since there is no way that I know of that a user would add or remove a package on a live site without rebooting, doing this once at start up seems to be the most accurate thing to do. How about lrpkg -i? I add packages to running systems all the time (well, at least occasionally :-). I like to keep things like tcpdump around for occasional network debugging, but I typically just manually load it from the CD when needed (and remove it when I'm done), rather than having it sit around live. NOTE: It's not easy to cleanly remove a package from a running system, but it's no too hard to do manually if you know what you're doing...adding a remove switch to lrpkg is on the to-do list, but as others will attest, you don't want to get me started on packaging system changes ;-) Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote: Mike Noyes schrieb: On Thu, 2002-07-11 at 07:51, Mike Noyes wrote: Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. Here is a small but significant addition to this sequence. It will allow retrieval of the tree in its 1.0 state. 1$ cvs -q tag R_1_0 2$ cp scriptb scriptc 3$ cvs add scriptc 4$ cvs ci -m added scriptc old filename was scriptb scriptc 5$ rm scriptb 6$ cvs remove scriptb 7$ cvs ci -m removed scriptb new filename is scriptc scriptb [snip] I recommend to tag every release with an appropriate label. So you can retrieve any old release or verify what is released. I also recommend to tag the latest release with somthing like 'latest' for easy retrieval. Manfred, Agreed. Tags are good. :-) I don't think this sequence will work because in line 5 you remove scriptb and in line 7 you try to checkin scriptb. I believe this sequence is correct, and a checkin is required to move the file to the Attic in the repository. ref. http://cvsbook.red-bean.com/cvsbook.html#Removing_Files http://cvsbook.red-bean.com/cvsbook.html#What_Happens_When_You_Remove_A_File I have no experience with cvs and from the man pages I could not determine if line 6 removes only the last version or all versions of scriptb. If it removes all versions you get the problem with version 0.9. I would use this sequence cvs -q tag R_1_0 cvs -f ci -m file renamed to scriptc scriptb From the cvs man page: commit [-lnR] [-m 'log_message' | -f file] [-r revision] [files...] Sometimes you may want to force a file to be committed even though it is unchanged; this is achieved with the -f flag, which also has the effect of disabling recursion (you can turn it back on with -R of course). How will this help? cvs -q tag -d MAIN scriptb mv scriptb scriptc cvs add scriptc cvs ci -m file renamed from scriptb scriptc This sequence is not tested. It is just what I can read from the man pages. Maybe you need additonally this line cvs remove scriptb but as mentioned, I don't know what exactly is removed. Maybe the tag MAIN cannot be deleted, although I couldn't find it in the man page. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Location for scripts during startup
On Thursday 11 July 2002 14:36, Charles Steinkuehler wrote: weblet runs script to gather all package conf files (/var/lib/lrpkg/*.conf files) to generate the configuration display component in weblet (to replace the hard coded one in the Dev Demo now) We can add an init.d script to do this w/o any problem. weblet runs script to gather weblet addon package conf files (/var/lib/lrpkg/w-xx.conf files) and to regenerate its /var/lib/lrpkg/weblet.conf file to these addon config files This is probably something for the init scripts to deal with (if required). Maybe an added button on the form to reload the init script via svi. The idea here is to simplify the weblet system so that there is a small base dashboard (much like it is now) with the ability to add new components and manage them as easily as adding additional lrp packages. Any startup-time config should be handled by the init scripts (/etc/init.d /etc/rc?.d/), but a lot of the site content should probably be generated on the fly...this shouldn't be too CPU intensive if a proper directory structure for weblet add-on packages is created. There is a project in progress to do this already...see the Richard's e-mail and weblet demo site. Add a directory in the cgi directory for placement of the seperate package modules. The module can be added to a package or manually this way w/o messing with lrpkg. A simple script that retrives a module list with ls would probably suffice. I am really against simply using the existing lrpkg system for this config unless we can text-to-html cat file and filter the file for option=value into a form decently. This option sounds more like a re-write of text-to-html and doesn't simplify the base configuration as much as I'm hoping. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Mike Noyes schrieb: On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote: Mike Noyes schrieb: On Thu, 2002-07-11 at 07:51, Mike Noyes wrote: Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. Here is a small but significant addition to this sequence. It will allow retrieval of the tree in its 1.0 state. 1$ cvs -q tag R_1_0 2$ cp scriptb scriptc 3$ cvs add scriptc 4$ cvs ci -m added scriptc old filename was scriptb scriptc 5$ rm scriptb 6$ cvs remove scriptb 7$ cvs ci -m removed scriptb new filename is scriptc scriptb [snip] I recommend to tag every release with an appropriate label. So you can retrieve any old release or verify what is released. I also recommend to tag the latest release with somthing like 'latest' for easy retrieval. Manfred, Agreed. Tags are good. :-) I don't think this sequence will work because in line 5 you remove scriptb and in line 7 you try to checkin scriptb. I believe this sequence is correct, and a checkin is required to move the file to the Attic in the repository. ref. http://cvsbook.red-bean.com/cvsbook.html#Removing_Files http://cvsbook.red-bean.com/cvsbook.html#What_Happens_When_You_Remove_A_File You are right. I was irritated by 'ci' (check in). 'commit' would make things easier to understand. Checking in a nonexisting file looks strange. I have no experience with cvs and from the man pages I could not determine if line 6 removes only the last version or all versions of scriptb. If it removes all versions you get the problem with version 0.9. I would use this sequence cvs -q tag R_1_0 cvs -f ci -m file renamed to scriptc scriptb From the cvs man page: commit [-lnR] [-m 'log_message' | -f file] [-r revision] [files...] Sometimes you may want to force a file to be committed even though it is unchanged; this is achieved with the -f flag, which also has the effect of disabling recursion (you can turn it back on with -R of course). How will this help? The intention was to get a final log message. You get it when you commit the remove. cvs -q tag -d MAIN scriptb mv scriptb scriptc cvs add scriptc cvs ci -m file renamed from scriptb scriptc This sequence is not tested. It is just what I can read from the man pages. Maybe you need additonally this line cvs remove scriptb but as mentioned, I don't know what exactly is removed. Maybe the tag MAIN cannot be deleted, although I couldn't find it in the man page. I had a quick look at the enforce scripts. You should not force all filenames (except Makefile) to lowercase. Some kernel modules have uppercase letters in their names. Also the README files are typically in uppercase. An X terminal dist would have big problems with that rule. Attic should not be allowed as name. -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
