Re: [leaf-devel] cvs structure

[davidMbrooke]

On Mon, 2010-11-22 at 23:11 +0100, KP Kirchdoerfer wrote:
> Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke:
> > On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote:
> > > David;
> > > 
> > > Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke:
> > > > On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> > > > > Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
> > > > > 
> > > > > Ok; I propose:
> > > > > - just "core" and "contrib" repository (names are not fixed), testing
> > > > > isn't needed   - we can also put packages in contrib which we
> > > > > consider for testing or provided as-is.
> > > > 
> > > > Just to make sure I understand 100%, some examples:
> > > >etc.lrp: Certainly part of "core". No debate.
> > > 
> > > Maybe this also debatable :)
> > > 
> > > The most radical way (besides opening it all) would be just to define
> > > "core" just as buildenv and buildtool itself. Which is the bare minimum
> > > to build packages on a definded base (uclibc version).
> > > Though even that raises pb's. What if a user wants to provide a complete
> > > new kernel arch? And in the developer guidelines and policies we asked
> > > to provide modules not in the package, but with modules.tgz
> > > 
> > > During 2.x and 3.x we thought about "core" mainly as "packages that are
> > > provided on the floppy image" - but as that donÄt exist any longer...,
> > > and it doesn't work very well in the long term.
> > > 
> > > >asterisk.lrp: Certainly part of "contrib" (only if it is fixed?)
> > > >aiccu.lrp: Not part of "core", since only relevant to some users,
> > > >but
> > > > 
> > > > you (kp) and I (dMb) would be willing to upgrade, test, repair etc.
> > > 
> > > Both belongs shurely to "contrib"
> > > 
> > > > Should we distinguish "supported" contrib from "unsupported" contrib?
> > > > Something like "primary" (instead of "core" - approx 10 packages that
> > > > EVERY user will need), "secondary" (tested and supported, but not
> > > > "core"), then "contrib" for the others?
> > > 
> > > Hmm, the idea of "approx 10 packages that every users need" is a good
> > > one. Your "secondary" and "contrib" maybe rephrased as "packages" and
> > > "testing"? (primary/packages/testing)
> > > 
> > > kp
> > 
> > Hi kp,
> > 
> > To me, "testing" implies a temporary state: "will move somewhere else
> > when testing is successful", which isn't quite what I had in mind. A
> > package in "contrib" will always stay in "contrib"...
> > 
> > In terms of packages (i.e. ignoring buildenv and buildtool) then "core"
> > or "primary" is:
> >- kernel (OK, not really a "package" as such...)
> >- initrd
> >- root
> >- etc
> >- modules
> > Would a system actually run with just this list (+ moddb + configdb)?
> > 
> > Then there are "mainstream" add-on packages:
> >- iptables
> >- shorwall
> >   - Hence also libm, perl
> >- ip6tables
> >- shorwall6
> >- dropbear
> >- dhcpcd
> >- dnsmasq
> >- mhttpd
> >- webconf
> >- A few more perhaps?
> > 
> > Others would be "contrib".
> > 
> > So maybe 3 categories: "core", "mainstream", "contrib" ???
> > 
> > dMb
> 
> David;
> 
> I've slept and thought over this the past weeks.
> In the meantime Erich has been added to the list of developers being able to 
> commit and it worked out pretty well.
> 
> I've made the experience in the past that too restrictive settings are more a 
> loss than a win.
> 
> So I think we may go with a more open-minded and easy-to-understand rule.
> 
> Current cvs should be open to every LEAF developers who asks for write 
> permission - assuming everyone is aware of the responsibility having write 
> permissions. 
> 
> A contrib section should be added with write permissions for everyone who has 
> been added as LEAF developer.
> 
> Sounds easy and effetive to me :)
> 
> kp

Hi kp,

I like to keep things simple so sure, let's go with what you propose.

In terms of write access there would be no difference between my "core"
and "mainstream" anyway. (Only difference would have been the level of
support and testing, and the intent to widen the development team.)

dMb



--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] cvs structure

[KP Kirchdoerfer]

Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke:
> On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote:
> > David;
> > 
> > Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke:
> > > On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> > > > Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
> > > > 
> > > > Ok; I propose:
> > > > - just "core" and "contrib" repository (names are not fixed), testing
> > > > isn't needed   - we can also put packages in contrib which we
> > > > consider for testing or provided as-is.
> > > 
> > > Just to make sure I understand 100%, some examples:
> > >etc.lrp: Certainly part of "core". No debate.
> > 
> > Maybe this also debatable :)
> > 
> > The most radical way (besides opening it all) would be just to define
> > "core" just as buildenv and buildtool itself. Which is the bare minimum
> > to build packages on a definded base (uclibc version).
> > Though even that raises pb's. What if a user wants to provide a complete
> > new kernel arch? And in the developer guidelines and policies we asked
> > to provide modules not in the package, but with modules.tgz
> > 
> > During 2.x and 3.x we thought about "core" mainly as "packages that are
> > provided on the floppy image" - but as that donÄt exist any longer...,
> > and it doesn't work very well in the long term.
> > 
> > >asterisk.lrp: Certainly part of "contrib" (only if it is fixed?)
> > >aiccu.lrp: Not part of "core", since only relevant to some users,
> > >but
> > > 
> > > you (kp) and I (dMb) would be willing to upgrade, test, repair etc.
> > 
> > Both belongs shurely to "contrib"
> > 
> > > Should we distinguish "supported" contrib from "unsupported" contrib?
> > > Something like "primary" (instead of "core" - approx 10 packages that
> > > EVERY user will need), "secondary" (tested and supported, but not
> > > "core"), then "contrib" for the others?
> > 
> > Hmm, the idea of "approx 10 packages that every users need" is a good
> > one. Your "secondary" and "contrib" maybe rephrased as "packages" and
> > "testing"? (primary/packages/testing)
> > 
> > kp
> 
> Hi kp,
> 
> To me, "testing" implies a temporary state: "will move somewhere else
> when testing is successful", which isn't quite what I had in mind. A
> package in "contrib" will always stay in "contrib"...
> 
> In terms of packages (i.e. ignoring buildenv and buildtool) then "core"
> or "primary" is:
>- kernel (OK, not really a "package" as such...)
>- initrd
>- root
>- etc
>- modules
> Would a system actually run with just this list (+ moddb + configdb)?
> 
> Then there are "mainstream" add-on packages:
>- iptables
>- shorwall
>   - Hence also libm, perl
>- ip6tables
>- shorwall6
>- dropbear
>- dhcpcd
>- dnsmasq
>- mhttpd
>- webconf
>- A few more perhaps?
> 
> Others would be "contrib".
> 
> So maybe 3 categories: "core", "mainstream", "contrib" ???
> 
> dMb

David;

I've slept and thought over this the past weeks.
In the meantime Erich has been added to the list of developers being able to 
commit and it worked out pretty well.

I've made the experience in the past that too restrictive settings are more a 
loss than a win.

So I think we may go with a more open-minded and easy-to-understand rule.

Current cvs should be open to every LEAF developers who asks for write 
permission - assuming everyone is aware of the responsibility having write 
permissions. 

A contrib section should be added with write permissions for everyone who has 
been added as LEAF developer.

Sounds easy and effetive to me :)

kp

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] cvs structure

[davidMbrooke]

On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote:
> David;
> 
> Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke:
> > On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> > > Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
> > > 
> > > Ok; I propose:
> > > - just "core" and "contrib" repository (names are not fixed), testing
> > > isn't needed   - we can also put packages in contrib which we consider
> > > for testing or provided as-is.
> > 
> > Just to make sure I understand 100%, some examples:
> > 
> >etc.lrp: Certainly part of "core". No debate.
> 
> Maybe this also debatable :)
> 
> The most radical way (besides opening it all) would be just to define "core" 
> just as buildenv and buildtool itself. Which is the bare minimum to build 
> packages on a definded base (uclibc version).
> Though even that raises pb's. What if a user wants to provide a complete new 
> kernel arch? And in the developer guidelines and policies we asked to provide 
> modules not in the package, but with modules.tgz
> 
> During 2.x and 3.x we thought about "core" mainly as "packages that are 
> provided on the floppy image" - but as that donÄt exist any longer..., and it 
> doesn't work very well in the long term.
> 
> >asterisk.lrp: Certainly part of "contrib" (only if it is fixed?)
> >aiccu.lrp: Not part of "core", since only relevant to some users, but
> > you (kp) and I (dMb) would be willing to upgrade, test, repair etc.
> 
> Both belongs shurely to "contrib"
>  
> > Should we distinguish "supported" contrib from "unsupported" contrib?
> > Something like "primary" (instead of "core" - approx 10 packages that
> > EVERY user will need), "secondary" (tested and supported, but not
> > "core"), then "contrib" for the others?
> 
> Hmm, the idea of "approx 10 packages that every users need" is a good one.
> Your "secondary" and "contrib" maybe rephrased as "packages" and "testing"?
> (primary/packages/testing)
> 
> kp

Hi kp,

To me, "testing" implies a temporary state: "will move somewhere else
when testing is successful", which isn't quite what I had in mind. A
package in "contrib" will always stay in "contrib"...

In terms of packages (i.e. ignoring buildenv and buildtool) then "core"
or "primary" is:
   - kernel (OK, not really a "package" as such...)
   - initrd
   - root
   - etc
   - modules
Would a system actually run with just this list (+ moddb + configdb)?

Then there are "mainstream" add-on packages:
   - iptables
   - shorwall
  - Hence also libm, perl
   - ip6tables
   - shorwall6
   - dropbear
   - dhcpcd
   - dnsmasq
   - mhttpd
   - webconf
   - A few more perhaps?

Others would be "contrib".

So maybe 3 categories: "core", "mainstream", "contrib" ???

dMb



--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] cvs structure

[KP Kirchdoerfer]

David;

Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke:
> On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> > Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
> > 
> > Ok; I propose:
> > - just "core" and "contrib" repository (names are not fixed), testing
> > isn't needed   - we can also put packages in contrib which we consider
> > for testing or provided as-is.
> 
> Just to make sure I understand 100%, some examples:
> 
>etc.lrp: Certainly part of "core". No debate.

Maybe this also debatable :)

The most radical way (besides opening it all) would be just to define "core" 
just as buildenv and buildtool itself. Which is the bare minimum to build 
packages on a definded base (uclibc version).
Though even that raises pb's. What if a user wants to provide a complete new 
kernel arch? And in the developer guidelines and policies we asked to provide 
modules not in the package, but with modules.tgz

During 2.x and 3.x we thought about "core" mainly as "packages that are 
provided on the floppy image" - but as that donÄt exist any longer..., and it 
doesn't work very well in the long term.

>asterisk.lrp: Certainly part of "contrib" (only if it is fixed?)
>aiccu.lrp: Not part of "core", since only relevant to some users, but
> you (kp) and I (dMb) would be willing to upgrade, test, repair etc.

Both belongs shurely to "contrib"
 
> Should we distinguish "supported" contrib from "unsupported" contrib?
> Something like "primary" (instead of "core" - approx 10 packages that
> EVERY user will need), "secondary" (tested and supported, but not
> "core"), then "contrib" for the others?

Hmm, the idea of "approx 10 packages that every users need" is a good one.
Your "secondary" and "contrib" maybe rephrased as "packages" and "testing"?
(primary/packages/testing)

kp

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] cvs structure

[Mike Noyes]

On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
-snip-
> Ok; I propose:
> - just "core" and "contrib" repository (names are not fixed), testing isn't 
> needed   - we can also put packages in contrib which we consider for testing 
> or provided as-is.
> - lrp's and sources are required for both to be inline with the SF 
> requirements.
> 
> About write permissons:
> contrib should be open to all leaf-developers, what about the core? We may 
> give write permissions to core by request...

Everyone,
Current CVSROOT/avail global access. Modify as necessary.

# Global access for all project members
avail||bin/packages/glibc-2.0
avail||bin/packages/glibc-2.1
avail||bin/packages/glibc-2.2
avail||bin/packages/nolibc
avail||bin/packages/uclibc-0.9/20/contrib
avail||bin/packages/uclibc-0.9/28/contrib
avail||doc/docmanager
avail||doc/howto
avail||doc/man
avail||doc/network_diagrams
avail||src/bering-uclibc/contrib

> opinions?

-- 
Mike Noyes 
http://sourceforge.net/users/mhnoyes/
SF.net Projects:  leaf, sourceforge/sitedocs


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] cvs structure

[davidMbrooke]

On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
> 
> Ok; I propose:
> - just "core" and "contrib" repository (names are not fixed), testing isn't 
> needed   - we can also put packages in contrib which we consider for testing 
> or provided as-is.

Just to make sure I understand 100%, some examples:

   etc.lrp: Certainly part of "core". No debate.
   asterisk.lrp: Certainly part of "contrib" (only if it is fixed?)
   aiccu.lrp: Not part of "core", since only relevant to some users, but
you (kp) and I (dMb) would be willing to upgrade, test, repair etc. 

Should we distinguish "supported" contrib from "unsupported" contrib?
Something like "primary" (instead of "core" - approx 10 packages that
EVERY user will need), "secondary" (tested and supported, but not
"core"), then "contrib" for the others?

> - lrp's and sources are required for both to be inline with the SF 
> requirements.
> 
> About write permissons:
> contrib should be open to all leaf-developers, what about the core? We may 
> give write permissions to core by request...

Access to "core" works OK by current mechanism, IMHO.

> opinions?
> 
> kp
> 



--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] cvs structure

[KP Kirchdoerfer]

Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
> 29.10.2010 20:29, KP Kirchdoerfer пишет:
> > - Shall we provide compiled packages, as we did with Bering-uClibc
> > ("packages page"), better ideas?
> 
> IMHO it'll be good to provide separate packages and prebuilt full image
> - like it was earlier.

ok; 

> > - What about write permissions in cvs, shall we revive the contrib
> > section (see
> > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Talk:Bering-
> > uClibc_4.x_-_Developer_Guide_-_Policies_and_Guidelines)
> 
> Yes, IMHO it'll be good.
> 

Ok; I propose:
- just "core" and "contrib" repository (names are not fixed), testing isn't 
needed   - we can also put packages in contrib which we consider for testing 
or provided as-is.
- lrp's and sources are required for both to be inline with the SF 
requirements.

About write permissons:
contrib should be open to all leaf-developers, what about the core? We may 
give write permissions to core by request...

opinions?

kp

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] CVS structure and buildtool

[Erich Titl]

Hi Martin

on 29.09.2010 20:12, Martin Hejl wrote:
> Hi Erich,
> 
>> Either way, what is the canonical way to keep an existing build
>> environment in sync with CVS. Buildtool does not check for modifications
>> once a package is built.
> since nobody else chimed in (and since I'm partly to blame for some of 
> the shortcomings of buildtool), I'll respond - I'm not aware of any 
> means of doing that, without starting from scratch.
> 

Thanks, I will dig a little into the structure and see what I can do.

Erich


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Mike Noyes]

On Wed, 2002-07-17 at 15:50, Michael D. Schleif wrote:
> [2] Since cvs does not retain group, mode nor ownership attributes, [1]
> is further complicated and requires another kludge to correct directory
> and files attributes.

Michael,
This should only be an issue when exporting for public distribution. The
recommended solution is a script to export, configure, and package your
release.

# Exporting For Public Distribution 
http://cvsbook.red-bean.com/cvsbook.html#Exporting_For_Public_Distribution

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Mike Noyes]

On Wed, 2002-07-17 at 15:50, Michael D. Schleif wrote:
> I've been considering using whatever structure I settle on as my
> development environment.  I have cvs setup on my own network and hope to
> integrate leaf development into my other development projects.  However,
> cvs doesn't lend itself to this end for several reasons:
> 
> [1] Each sandbox includes cvs directories under each directory in the
> project.  So, rolling up the hierarchy directly into an LRP is
> cumbersome.  cvs export only adds to the kludge.

Michael,
I believe a module alias will solve this problem.

> [2] Since cvs does not retain group, mode nor ownership attributes, [1]
> is further complicated and requires another kludge to correct directory
> and files attributes.

This is a problem. CVS only tracks the x bit of files. I think there is
a workaround, but I can't remember it right now.

> [3] I still have not figured out how to force synchronization between
> cvs revision numbers and project source revision numbers.

You can't. Tags allow you to indicate release versions.

> [4] All of this makes inclusion of /package/.lrp an
> absolute must!
> 
> If anybody has overcome any of these obstacles, I'd appreciate
> enlightenment . . .

I hope some of this information was useful.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Michael D. Schleif]

David Douthitt wrote:

[ snip ]

> My model has been the following:
> 
> archives/
>   .tar.gz
>   .bz2
>   ...
> 
> iproute2/
>   distinfo
>   Makefile
>   patches/
> .diff
> .diff
> ...
>   work/ {temporary dir; created and used to compile within}
>   binaries/ {temporary dir; created and stores binaries ONLY (no path)}
>   world/{temporary dir; created and used to store full paths
>  and all files needed within the structure}
> 
> /
> ...
> 
> My current lrp "package" setup was to have the following:
> 
> iproute2-/
>   lrp/ {created}
> ...
> 
> Under lrp/ there is a Makefile which contains all of the targets to make packages, 
>etc.
> There is also a directory like world/ above which contains all paths and a Makefile
> in each directory that needs to have a binary in it.
> 
> After this lrp/ directory is correctly configured, then the entire directory is
> "wrapped up" into a *.diff file and saved with the unmodified source archive.  
>Examples
> of this can be found in the Oxygen/LEAF Resource CDROM.
> 
> Perhaps what I will do is to use this patch as a regular patch in the CVS ports tree
> and add the patch to the source code, then use it to create packages at will.

I've been considering using whatever structure I settle on as my
development environment.  I have cvs setup on my own network and hope to
integrate leaf development into my other development projects.  However,
cvs doesn't lend itself to this end for several reasons:

[1] Each sandbox includes cvs directories under each directory in the
project.  So, rolling up the hierarchy directly into an LRP is
cumbersome.  cvs export only adds to the kludge.

[2] Since cvs does not retain group, mode nor ownership attributes, [1]
is further complicated and requires another kludge to correct directory
and files attributes.

[3] I still have not figured out how to force synchronization between
cvs revision numbers and project source revision numbers.

[4] All of this makes inclusion of /package/.lrp an
absolute must!

If anybody has overcome any of these obstacles, I'd appreciate
enlightenment . . .

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[David Douthitt]

On Wed, Jul 17, 2002 at 03:21:32PM -0500, Michael D. Schleif wrote:
> 
> Jeff Newmiller wrote:

> > CVS is designed to handle directories full of information... so a
> > directory tree of html documents is a natural thing to enter.
> > 
> > An idea...
> > 
> >   net-snmp/
> > README.txt
> > package/
> >   net-snmp.lrp
> > target/
> >   etc/
> > blahblah
> >   usr/
> > bin/
> >   snmpbinary
> >   ...
> > doc/
> >   index.html
> >   images/
> > image1.jpg
> >   ...
> > src/
> >   sourcefiles...
> 
> [ snip ]
> 
> I took a liking to this structure, which you can see here:
> 
> 
> 
> I appreciate *ALL* feedback on this infrastructure, before I get carried
> away with further additions to cvs.
> 
> What do you think?

My model has been the following:

archives/
  .tar.gz
  .bz2
  ...

iproute2/
  distinfo
  Makefile
  patches/
.diff
.diff
...
  work/ {temporary dir; created and used to compile within}
  binaries/ {temporary dir; created and stores binaries ONLY (no path)}
  world/{temporary dir; created and used to store full paths
 and all files needed within the structure}

/
...

My current lrp "package" setup was to have the following:

iproute2-/
  lrp/ {created}
...

Under lrp/ there is a Makefile which contains all of the targets to make packages, etc.
There is also a directory like world/ above which contains all paths and a Makefile
in each directory that needs to have a binary in it.

After this lrp/ directory is correctly configured, then the entire directory is
"wrapped up" into a *.diff file and saved with the unmodified source archive.  Examples
of this can be found in the Oxygen/LEAF Resource CDROM.

Perhaps what I will do is to use this patch as a regular patch in the CVS ports tree
and add the patch to the source code, then use it to create packages at will.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Michael D. Schleif]

Jeff Newmiller wrote:
> 
> On Wed, 10 Jul 2002, Michael D. Schleif wrote:

[ snip ]

> > I am starting to realize that, perhaps, I should take a directory based
> > approach to helices' cvs tree.
> >
> > I have not settled on any particular structure.  However, I am wondering
> > about several things:

[ snip ]

> CVS is designed to handle directories full of information... so a
> directory tree of html documents is a natural thing to enter.
> 
> An idea...
> 
>   net-snmp/
> README.txt
> package/
>   net-snmp.lrp
> target/
>   etc/
> blahblah
>   usr/
> bin/
>   snmpbinary
>   ...
> doc/
>   index.html
>   images/
> image1.jpg
>   ...
> src/
>   sourcefiles...

[ snip ]

I took a liking to this structure, which you can see here:



I appreciate *ALL* feedback on this infrastructure, before I get carried
away with further additions to cvs.

What do you think?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[George Georgalis]

On Wed, Jul 10, 2002 at 01:01:27PM -0700, Jeff Newmiller wrote:
>On Wed, 10 Jul 2002, Michael D. Schleif wrote:

>CVS is designed to handle directories full of information... so a
>directory tree of html documents is a natural thing to enter.
>
>An idea...
>
>  net-snmp/
>README.txt
>package/
>  net-snmp.lrp
>target/
>  etc/
>blahblah
>  usr/
>bin/
>  snmpbinary
>  ...
>doc/
>  index.html
>  images/
>image1.jpg
>  ...
>src/
>  sourcefiles...
>
>Let CVS deal with versioning.

Yeah, I was thinking about http/ftp access. Looks good.

// George


-- 
GEORGE GEORGALIS, System Admin/Architectcell: 347-451-8229 
Security Services, Web, Mail,mailto:[EMAIL PROTECTED] 
File, Print, DB and DNS Servers.   http://www.galis.org/george 



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[George Georgalis]

On Wed, Jul 10, 2002 at 02:19:58PM -0500, Michael D. Schleif wrote:

>[1] Should I have separate trees for different underlying versions of
>net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
>building and committing both v4.2.5 and the totally different
>distribution v5.x.  So, one line of thinking is like this:
>
>devel/helices/net-snmp/v4.2.4/netsnmp.lrp
>devel/helices/net-snmp/v4.2.4/netsnmpd.lrp

Looks good to me, would allow for recursive wget --no-parent or ncftp -R
and version management would be a simpler. A copy of the current as
devel/helices/net-snmp/current/netsnmpd.lrp
or a zero legnth file 
devel/helices/net-snmp/current-is-v5.0.2
are also helpful; get devel/helices/net-snmp/current-* | sed | ncftpget -R v5.0.2


> presents several
>TXT files that, once clicked on, present descriptive text regarding the
>LRP's that reside in versioned directories below this one.  Another
>example is Jacques Nilo's 
>wonderful page that links to installation and troubleshooting
>information.  How are we to do this under cvs?

I would put the txt files in the version directores for which they
belong.  At some point (maybe even by a cgi to select components) a
custom disk image might be generated, such a program would have no
trouble separating out .txt and .lrp files.

// George

-- 
GEORGE GEORGALIS, System Admin/Architectcell: 347-451-8229 
Security Services, Web, Mail,mailto:[EMAIL PROTECTED] 
File, Print, DB and DNS Servers.   http://www.galis.org/george 



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
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]

Ugh, I just reverted to the prior enforce script. I'll take a look at it
again in the morning.

Currently lowercase name enforcement is active.


On Tue, 2002-07-16 at 17:12, Mike Noyes wrote:
> Everyone,
> I just removed the lowercase enforcement from our repository. If win
> clients start leaving broken stub files in our repository, we'll need to
> reexamine this issue.
> 
> 
> On Thu, 2002-07-11 at 16:59, Mike Noyes wrote:
> > On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> > > 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.
> > 
> > I believe this was done to address the following problem:
> > Introduction to SourceForge.net Project CVS Services
> > https://sourceforge.net/docman/display_doc.php?docid=768&group_id=1
> > Case Sensitivity
> > When a developer performs certain types of CVS operations,
> > specifically "cvs add" and "cvs remove", CVS checks the listing
> > of already-deleted files for that directory (i.e. the files in
> > the Attic for that directory) to see if there is a match of the
> > same filename. There is a difference between what MS
> > Windows-based systems consider a match and what case-sensitive
> > operating systems, such as Linux (which is used to provide the
> > project CVS services), see as a match in these cases. If the
> > filename match does not occur on the server, but there would be
> > a case-insensitive match, the Windows-based CVS client will
> > abort its operation and leave a broken stub file within the
> > repository, which must be removed by SourceForge.net staff.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

Everyone,
I just removed the lowercase enforcement from our repository. If win
clients start leaving broken stub files in our repository, we'll need to
reexamine this issue.


On Thu, 2002-07-11 at 16:59, Mike Noyes wrote:
> On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> > 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.
> 
> I believe this was done to address the following problem:
> Introduction to SourceForge.net Project CVS Services
> https://sourceforge.net/docman/display_doc.php?docid=768&group_id=1
> Case Sensitivity
> When a developer performs certain types of CVS operations,
> specifically "cvs add" and "cvs remove", CVS checks the listing
> of already-deleted files for that directory (i.e. the files in
> the Attic for that directory) to see if there is a match of the
> same filename. There is a difference between what MS
> Windows-based systems consider a match and what case-sensitive
> operating systems, such as Linux (which is used to provide the
> project CVS services), see as a match in these cases. If the
> filename match does not occur on the server, but there would be
> a case-insensitive match, the Windows-based CVS client will
> abort its operation and leave a broken stub file within the
> repository, which must be removed by SourceForge.net staff.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[David Douthitt]

On Wed, Jul 10, 2002 at 01:14:07PM -0700, Mike Noyes wrote:
> On Wed, 2002-07-10 at 13:01, Jeff Newmiller wrote:
> > David Douthitt has advocated (and it sounds good to me but I haven't done
> > it myself) a mechanism whereby sources obtained from other sources are
> > kept in original form and a parallel directory containing patchfiles and
> > compilation instructions is generated to allow LEAF-specific modifications
> > to be maintained separate from the original source tree if
> > necessary.  Read the archives... :)
> 
> Jeff,
> David's Ports system for packages has my vote for our src/packages tree.
> However, there may be problems with it that I'm unaware of, because I'm
> not a programmer.
> 
> Oxygen base in Ports form:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ddouthitt/base/

>From having worked with FreeBSD extensively for several months now,
I've been discovering more and more about the FreeBSD ports system
that I like.  I'll be revisiting the CVS tree and possibly updating it.

I've been away for a bit, but hope to dive into active development soon.



---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> I had a quick look at the enforce scripts.

Manfred,
Thanks for taking a look. :-)
Note: the enforce scripts were written by Jacob Moorman, and copied from
the sitedocs cvsroot. I modified the directory and permissions files for
our repository.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sitedocs/CVSROOT/

> 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.

I believe this was done to address the following problem:
Introduction to SourceForge.net Project CVS Services
https://sourceforge.net/docman/display_doc.php?docid=768&group_id=1
Case Sensitivity
When a developer performs certain types of CVS operations,
specifically "cvs add" and "cvs remove", CVS checks the listing
of already-deleted files for that directory (i.e. the files in
the Attic for that directory) to see if there is a match of the
same filename. There is a difference between what MS
Windows-based systems consider a match and what case-sensitive
operating systems, such as Linux (which is used to provide the
project CVS services), see as a match in these cases. If the
filename match does not occur on the server, but there would be
a case-insensitive match, the Windows-based CVS client will
abort its operation and leave a broken stub file within the
repository, which must be removed by SourceForge.net staff.


> Attic should not be allowed as name.

This sounds like a good idea. I'll try to talk with Jacob about it
tomorrow.

-- 
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]

[Manfred Schuler]

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

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

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] CVS structure ??? [LONG]

[Manfred Schuler]

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] CVS structure ??? [LONG]

[Mike Noyes]

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=detail&aid=547717&group_id=1&atid=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]

[Manfred Schuler]

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=detail&aid=574291&group_id=1&atid=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=detail&aid=547717&group_id=1&atid=21
Removing 'x' bit should do no harm
> 
> [ 547118 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=547118&group_id=1&atid=21
> 
Removing 'x' bit should do no harm
> [ 525177 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=525177&group_id=1&atid=21
> 
top level directory, ok
> [ #513309 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=513309&group_id=1&atid=21
> 
top level directory, ok
> [ #503058 ] CVS repository clean-up: leaf
> 
>https://sourceforge.net/tracker/index.php?func=detail&aid=503058&group_id=1&atid=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] CVS structure ??? [LONG]

[Manfred Schuler]

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

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

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=detail&aid=574291&group_id=1&atid=21

[ 547717 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=547717&group_id=1&atid=21

[ 547118 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=547118&group_id=1&atid=21

[ 525177 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=525177&group_id=1&atid=21

[ #513309 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=513309&group_id=1&atid=21

[ #503058 ] CVS repository clean-up: leaf
https://sourceforge.net/tracker/index.php?func=detail&aid=503058&group_id=1&atid=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]

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]

[Mike Noyes]

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]

[Mike Noyes]

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]

[Manfred Schuler]

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=1&atid=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]

[Mike Noyes]

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=1&atid=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]

[Manfred Schuler]

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=1&atid=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]

[guitarlynn]

On Wednesday 10 July 2002 19:41, Michael D. Schleif wrote:

> Yes, these are our (leaf) _cvs_ versions.  However, how can a user
> select net-snmp v4.2.4 when my net-snmp version is 1.1?

Well, the editor session that pops up during a commit can be avoided
with the -m "text" switch added to the commit command... I use for
notes based on the change(s) from earlier CVS versions of the same
package. You can use this to differeniate between net-snmp v4.2.4, 
4.2.5, and 5.0.1 (not to mention any other notables you would like
to add). As I am working on doing, if you would like certain versions
of the same CVS file(s) presented in a clear and special manner, simply
link them from a web page that presents this information. 

> > > What should I, joe-leaf-user, expect to find while perusing
> > > ViewCVS?
> >

Joe-User is usually looking for an exact package in CVS rather than
aimlessly attempting to find something random. I think most major
software groups use CVS from linked web pages as well.


> Right now, I'm only thinking about what goes under my devel/helices
> tree.  How that gets tied into dcd, bering, or whatever, is another
> issue, which I've decided to ignore for the moment.  Remember, this
> all started with your request to me to commit my net-snmp packages. 
> I committed the LRP's only, and since I've begun to plan committing
> several other items.  It's this planning that has me hung now; but,
> I'd really like to put that behind me ;>

I think you are doing the smartest thing by planning you tree. A good
plan will save tons of time and effort at a later date by foreseeable
circumstances.
-- 

~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
Two, two, TWO treats in one.
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]

On Wed, 2002-07-10 at 17:41, Michael D. Schleif wrote:
> 
> Mike Noyes wrote:
> > 
> > On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> > CVS retains all previous versions of a file in the repository. You can
> > specify a specific version for retrieval.
> > 
> > Example:
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp
> > 
> > Download version 1.10
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream
> > 
> > Download version 1.1
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream
> 
> Yes, these are our (leaf) _cvs_ versions.  However, how can a user
> select net-snmp v4.2.4 when my net-snmp version is 1.1?

Michael,
A simple href on a web page will work. Lynn is already doing this on his
pages.

net-snmp.lrp v4.2.4

http://leaf-project.org/devel/guitarlynn/

> > > 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.
> 
> If this is all that is available to us -- and, really, such requests
> seem to be available to only a few, like you, Mike -- then, it behooves
> me to select a good structure now, before I have to request alot of
> changes.  That is why I belabor this point now.

I understand your concerns, but the SF staff are happy to make any
changes we may need (move, rename, remove). You can talk with them on
irc if you want to verify this(irc.slashnet.org channel #sourceforge).
BTW, I'm there most of the day too.

Note: changes of this type take from 24 to 72 hours of working days to
process. A project admin usually needs to make the requested change.

Note 2: I keep a log of all SF support requests that are opened for our
project in this task.
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=45595&group_id=13751&group_project_id=5257

Note 3: If you have a problem with one of the SF services please add a
comment to this task.
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=45594&group_id=13751&group_project_id=5257

> > > What should I, joe-leaf-user, expect to find while perusing ViewCVS?
> > 
> > doc -- released documentation
> > bin/packages -- released packages sorted by library type/revision
> > 
> > binary files for LEAF release/branch tree (write access controlled
> > by lead developer)
> > /bering
> > /dachstein
> > /oxygen
> > /packetfilter
> > /wisp-dist
> > /wrp
> > src -- source code
> 
> Is that like Jeff's earlier directory structure outline, or is this
> referring to the text to include in the cvs commit blurb?

This is the current LEAF repository structure. see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/


> > Think of the devel tree as individual repositories, and the doc, bin,
> > and src trees as community resources. Did that help?
> 
> Right now, I'm only thinking about what goes under my devel/helices
> tree.  How that gets tied into dcd, bering, or whatever, is another
> issue, which I've decided to ignore for the moment.  Remember, this all
> started with your request to me to commit my net-snmp packages.  I
> committed the LRP's only, and since I've begun to plan committing
> several other items.  It's this planning that has me hung now; but, I'd
> really like to put that behind me ;>

Understood. I'm not sure how I can assist you with this though, as each
developer has different ideas of what a repository should look like.
Maybe these links will help.

CVS Documentation
http://www.cvshome.org/docs/

# Open Source Development with CVS by Karl Fogel
http://cvsbook.red-bean.com/cvsbook.html

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Michael D. Schleif]

Mike Noyes wrote:
> 
> On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> >
> > Jeff Newmiller wrote:
> > >
> > > On Wed, 10 Jul 2002, Michael D. Schleif wrote:
> >
> > > > [1] Should I have separate trees for different underlying versions of
> > > > net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
> > > > building and committing both v4.2.5 and the totally different
> > > > distribution v5.x.  So, one line of thinking is like this:
> > > >
> > > > devel/helices/net-snmp/v4.2.4/netsnmp.lrp ...
> > > > devel/helices/net-snmp/v4.2.5/netsnmp.lrp ...
> > > > devel/helices/net-snmp/v5.0.2/netsnmp.lrp ...
> > >
> > > This seems quite the wrong direction.  CVS is supposed to manage
> > > versioning completely independently of the directory structure.
> >
> > Yes, I agree.  However, I am dealing with somebody else's software and
> > making it suitable for leaf.  Obviously, I can have several iterations
> > of net-snmp v4.2.4 that address various leaf concerns.
> 
> Michael,
> CVS retains all previous versions of a file in the repository. You can
> specify a specific version for retrieval.
> 
> Example:
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp
> 
> Download version 1.10
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream
> 
> Download version 1.1
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream

Yes, these are our (leaf) _cvs_ versions.  However, how can a user
select net-snmp v4.2.4 when my net-snmp version is 1.1?

> > 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.

If this is all that is available to us -- and, really, such requests
seem to be available to only a few, like you, Mike -- then, it behooves
me to select a good structure now, before I have to request alot of
changes.  That is why I belabor this point now.

[ snip ]

> > What should I, joe-leaf-user, expect to find while perusing ViewCVS?
> 
> doc -- released documentation
> bin/packages -- released packages sorted by library type/revision
> 
> binary files for LEAF release/branch tree (write access controlled
> by lead developer)
> /bering
> /dachstein
> /oxygen
> /packetfilter
> /wisp-dist
> /wrp
> src -- source code

Is that like Jeff's earlier directory structure outline, or is this
referring to the text to include in the cvs commit blurb?

> > I worry, however, if every developer goes about creating some adhoc
> > structure to their liking . . .
> 
> Think of the devel tree as individual repositories, and the doc, bin,
> and src trees as community resources. Did that help?

Right now, I'm only thinking about what goes under my devel/helices
tree.  How that gets tied into dcd, bering, or whatever, is another
issue, which I've decided to ignore for the moment.  Remember, this all
started with your request to me to commit my net-snmp packages.  I
committed the LRP's only, and since I've begun to plan committing
several other items.  It's this planning that has me hung now; but, I'd
really like to put that behind me ;>

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
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]

On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> 
> Jeff Newmiller wrote:
> > 
> > On Wed, 10 Jul 2002, Michael D. Schleif wrote:
> 
> [ snip ]
> 
> > > [1] Should I have separate trees for different underlying versions of
> > > net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
> > > building and committing both v4.2.5 and the totally different
> > > distribution v5.x.  So, one line of thinking is like this:
> > >
> > > devel/helices/net-snmp/v4.2.4/netsnmp.lrp ...
> > > devel/helices/net-snmp/v4.2.5/netsnmp.lrp ...
> > > devel/helices/net-snmp/v5.0.2/netsnmp.lrp ...
> > 
> > This seems quite the wrong direction.  CVS is supposed to manage
> > versioning completely independently of the directory structure.
> 
> Yes, I agree.  However, I am dealing with somebody else's software and
> making it suitable for leaf.  Obviously, I can have several iterations
> of net-snmp v4.2.4 that address various leaf concerns.

Michael,
CVS retains all previous versions of a file in the repository. You can
specify a specific version for retrieval.

Example:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp

Download version 1.10
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream

Download version 1.1
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream


> 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=1&atid=21


> During commit, I am presented with an editor session, in which I am
> allowed to enter text.  I wonder whether or not this allowance should
> rather be a requirement?
> 
> What is it that this commit blurb is intended to convey?  Is this
> intended to be an introduction to the package?  A simple statement of
> my/leaf or somebody else's version upgraded to whatever?
> 
> What should I, joe-leaf-user, expect to find while perusing ViewCVS?

doc -- released documentation
bin/packages -- released packages sorted by library type/revision

binary files for LEAF release/branch tree (write access controlled
by lead developer)
/bering
/dachstein
/oxygen
/packetfilter
/wisp-dist
/wrp
src -- source code 


> I worry, however, if every developer goes about creating some adhoc
> structure to their liking . . .

Think of the devel tree as individual repositories, and the doc, bin,
and src trees as community resources. Did that help?

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
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]

On Wed, 2002-07-10 at 15:39, Charles Steinkuehler wrote:
> > Under this scenario, committing to cvs directory structures, cvs is
> > responsible for knowing whether or not a specific file or directory
> > has changed?  Any change, including mod/grp/own?
> 
> CVS doesn't track file permissions or ownership...just contents.

Charles,
CVS does track the x bit of committed files. The x bit is set on import
and add commands.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Charles Steinkuehler]

> Yes, I agree.  However, I am dealing with somebody else's software and
> making it suitable for leaf.  Obviously, I can have several iterations
> of net-snmp v4.2.4 that address various leaf concerns.
>
> Also, I must be prepared for somebody else's version upgrades causing
> problems that do not exist in previous versions.  For most part,
> net-snmp v4.2.5 fixes a number of things a small number of people
found
> problematic in v4.2.4.  However, v4.2.5 also created problems for a
> small number of users that did not exist in v4.2.4.
>
> So, in reality, my package has two (2) versioning systems running in
> parallel: somebody else's and leaf/mine.  How can cvs facilitate this
> distinction?

See "Open source development with CVS" by Karl Fogel (Coriolis
press...also, parts are available online).  The last part of chapter 6
has a section on using vendor branches to track 3rd party software.
This basically describes how to import an external code-base into a
local CVS tree, using CVS to track any local changes, and finally how to
import a new release, if/when it becomes available from the 3rd party
(ie the NetSnmp folks).

> Under this scenario, committing to cvs directory structures, cvs is
> responsible for knowing whether or not a specific file or directory
has
> changed?  Any change, including mod/grp/own?

CVS doesn't track file permissions or ownership...just contents.

> 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?

Moving files once they're in CVS is ugly...see the above reference for
details.  There's a CVS replacement in the works that tries to clean up
a bunch of CVS's rough edges, but it's not in widespread use yet.

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Michael D. Schleif]

Jeff Newmiller wrote:
> 
> On Wed, 10 Jul 2002, Michael D. Schleif wrote:

[ snip ]

> > [1] Should I have separate trees for different underlying versions of
> > net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
> > building and committing both v4.2.5 and the totally different
> > distribution v5.x.  So, one line of thinking is like this:
> >
> > devel/helices/net-snmp/v4.2.4/netsnmp.lrp ...
> > devel/helices/net-snmp/v4.2.5/netsnmp.lrp ...
> > devel/helices/net-snmp/v5.0.2/netsnmp.lrp ...
> 
> This seems quite the wrong direction.  CVS is supposed to manage
> versioning completely independently of the directory structure.

Yes, I agree.  However, I am dealing with somebody else's software and
making it suitable for leaf.  Obviously, I can have several iterations
of net-snmp v4.2.4 that address various leaf concerns.

Also, I must be prepared for somebody else's version upgrades causing
problems that do not exist in previous versions.  For most part,
net-snmp v4.2.5 fixes a number of things a small number of people found
problematic in v4.2.4.  However, v4.2.5 also created problems for a
small number of users that did not exist in v4.2.4.

So, in reality, my package has two (2) versioning systems running in
parallel: somebody else's and leaf/mine.  How can cvs facilitate this
distinction?

> > [2] Perhaps, my net-snmp package, for instance, should be in cvs in
> > expanded form, so that when only one (1) or a few file contents change,
> > that will be directly reflected in cvs?  Under this scenario, when only
> > a single file -- perhaps, the primary binary? -- is changed, users can
> > checkout only that file.
> 
> This sounds good.

I am new to cvs; so, bear with me.

Under this scenario, committing to cvs directory structures, cvs is
responsible for knowing whether or not a specific file or directory has
changed?  Any change, including mod/grp/own?

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?

> > [3] Item [2] presents a difficulty when a user wants the whole LRP
> > package as one (1) LRP file.  Is there some way to properly archive and
> > compress a cvs directory tree and check that out?
> 
> If possible, but probably not. Probably should use both expanded and
> packaged form.

Yes, I like this, too.

> > [4] I am still confused on how best to handle package descriptions.
> >  presents several
> > TXT files that, once clicked on, present descriptive text regarding the
> > LRP's that reside in versioned directories below this one.  Another
> > example is Jacques Nilo's 
> > wonderful page that links to installation and troubleshooting
> > information.  How are we to do this under cvs?
> 
> After presenting two approaches you use the pronoun "this"??

I am sorry; but, I lumped these two together to make a generic
documentation point.

During commit, I am presented with an editor session, in which I am
allowed to enter text.  I wonder whether or not this allowance should
rather be a requirement?

What is it that this commit blurb is intended to convey?  Is this
intended to be an introduction to the package?  A simple statement of
my/leaf or somebody else's version upgraded to whatever?

What should I, joe-leaf-user, expect to find while perusing ViewCVS?

> CVS is designed to handle directories full of information... so a
> directory tree of html documents is a natural thing to enter.
> 
> An idea...
> 
>   net-snmp/
> README.txt
> package/
>   net-snmp.lrp
> target/
>   etc/
> blahblah
>   usr/
> bin/
>   snmpbinary
>   ...
> doc/
>   index.html
>   images/
> image1.jpg
>   ...
> src/
>   sourcefiles...
> 
> Let CVS deal with versioning.

I rather like this structure.  It is intuitive to navigate, complex
enough to deal with complex packages, and simple enough to maintain.

I worry, however, if every developer goes about creating some adhoc
structure to their liking . . .

OK, yes, it is time to stop worrying about whatever shenanigans some
other might do ;>

> David Douthitt has advocated (and it sounds good to me but I haven't done
> it myself) a mechanism whereby sources obtained from other sources are
> kept in original form and a parallel directory containing patchfiles and
> compilation instructions is generated to allow LEAF-specific modifications
> to be maintained separate from the original source tree if
> necessary.  Read the archives... :)

I've been looking at what others have done and when I looked at David's,
I saw a directory structure that didn't mean anything to me and could
not find any files, other than Makefile.  What am I missing?

-- 

Bes

Re: [Leaf-devel] CVS structure ???

[Mike Noyes]

On Wed, 2002-07-10 at 13:01, Jeff Newmiller wrote:
> David Douthitt has advocated (and it sounds good to me but I haven't done
> it myself) a mechanism whereby sources obtained from other sources are
> kept in original form and a parallel directory containing patchfiles and
> compilation instructions is generated to allow LEAF-specific modifications
> to be maintained separate from the original source tree if
> necessary.  Read the archives... :)

Jeff,
David's Ports system for packages has my vote for our src/packages tree.
However, there may be problems with it that I'm unaware of, because I'm
not a programmer.

Oxygen base in Ports form:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ddouthitt/base/

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Jeff Newmiller]

On Wed, 10 Jul 2002, Michael D. Schleif wrote:

> 
> Mike and I were discussing cvs off-list.  Since much of this is
> un-structured now, perhaps, we can impose some user-friendly and
> consistent form on our cvs tree.

A topic with a long history...

> I am starting to realize that, perhaps, I should take a directory based
> approach to helices' cvs tree.
> 
> I have not settled on any particular structure.  However, I am wondering
> about several things:
> 
> [1] Should I have separate trees for different underlying versions of
> net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
> building and committing both v4.2.5 and the totally different
> distribution v5.x.  So, one line of thinking is like this:
> 
> devel/helices/net-snmp/v4.2.4/netsnmp.lrp
> devel/helices/net-snmp/v4.2.4/netsnmpd.lrp
> devel/helices/net-snmp/v4.2.4/nettrapd.lrp
> devel/helices/net-snmp/v4.2.5/netsnmp.lrp
> devel/helices/net-snmp/v4.2.5/netsnmpd.lrp
> devel/helices/net-snmp/v4.2.5/nettrapd.lrp
> devel/helices/net-snmp/v5.0.2/netsnmp.lrp
> devel/helices/net-snmp/v5.0.2/netsnmpd.lrp
> devel/helices/net-snmp/v5.0.2/nettrapd.lrp
> . . .

This seems quite the wrong direction.  CVS is supposed to manage
versioning completely independently of the directory structure.

> [2] Perhaps, my net-snmp package, for instance, should be in cvs in
> expanded form, so that when only one (1) or a few file contents change,
> that will be directly reflected in cvs?  Under this scenario, when only
> a single file -- perhaps, the primary binary? -- is changed, users can
> checkout only that file.

This sounds good.

> [3] Item [2] presents a difficulty when a user wants the whole LRP
> package as one (1) LRP file.  Is there some way to properly archive and
> compress a cvs directory tree and check that out?

If possible, but probably not. Probably should use both expanded and
packaged form.

> [4] I am still confused on how best to handle package descriptions. 
>  presents several
> TXT files that, once clicked on, present descriptive text regarding the
> LRP's that reside in versioned directories below this one.  Another
> example is Jacques Nilo's 
> wonderful page that links to installation and troubleshooting
> information.  How are we to do this under cvs?

After presenting two approaches you use the pronoun "this"??

CVS is designed to handle directories full of information... so a
directory tree of html documents is a natural thing to enter.

An idea...

  net-snmp/
README.txt
package/
  net-snmp.lrp
target/
  etc/
blahblah
  usr/
bin/
  snmpbinary
  ...
doc/
  index.html
  images/
image1.jpg
  ...
src/
  sourcefiles...

Let CVS deal with versioning.

David Douthitt has advocated (and it sounds good to me but I haven't done
it myself) a mechanism whereby sources obtained from other sources are
kept in original form and a parallel directory containing patchfiles and
compilation instructions is generated to allow LEAF-specific modifications
to be maintained separate from the original source tree if
necessary.  Read the archives... :)

---
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
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Mike Noyes]

On Wed, 2002-07-10 at 12:19, Michael D. Schleif wrote:
> 
> Mike and I were discussing cvs off-list.  Since much of this is
> un-structured now, perhaps, we can impose some user-friendly and
> consistent form on our cvs tree.

Michael,
Remember that your devel/helices tree structure is entirely up to you.

We have structures for our bin and doc trees, but haven't come to a
consensus on src yet.

> I am starting to realize that, perhaps, I should take a directory based
> approach to helices' cvs tree.

This is a good idea.

> I have not settled on any particular structure.  However, I am wondering
> about several things:
> 
> [1] Should I have separate trees for different underlying versions of
> net-snmp?

I don't recommend using version specific names for directories or files
in cvs if at all possible.


> [2] Perhaps, my net-snmp package, for instance, should be in cvs in
> expanded form, so that when only one (1) or a few file contents change,
> that will be directly reflected in cvs?  Under this scenario, when only
> a single file -- perhaps, the primary binary? -- is changed, users can
> checkout only that file.

Again, the structure of your devel/helices tree is up to you.

> [3] Item [2] presents a difficulty when a user wants the whole LRP
> package as one (1) LRP file.  Is there some way to properly archive and
> compress a cvs directory tree and check that out?

You can tag the files, and export them for packaging purposes. ref.
http://cvsbook.red-bean.com/cvsbook.html#Exporting_For_Public_Distribution

Packages that are ready for general consumption should be committed to
our bin/packages tree in cvs. I hope to have this tree exporting nightly
to our pub directory on the SF shell server this month.

> [4] I am still confused on how best to handle package descriptions. 
>  presents several
> TXT files that, once clicked on, present descriptive text regarding the
> LRP's that reside in versioned directories below this one.  Another
> example is Jacques Nilo's 
> wonderful page that links to installation and troubleshooting
> information.  How are we to do this under cvs?

I'd like people to start familiarizing themselves with phpWebSite (see
demo link below). Instead of using the devel tree on the shell server
for web content I'd like use to use phpWebSite. Page creation and menu
placement is fairly easy. Everyone of our project members has an
admin/author account for phpWebSite. Contact me off list if you don't
have your login information yet.

Note: the demo is using 0.8.2 and we are using 0.8.1.1.
http://phpwebsite.appstate.edu/demo/

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] CVS structure ???

[Michael D. Schleif]

Mike and I were discussing cvs off-list.  Since much of this is
un-structured now, perhaps, we can impose some user-friendly and
consistent form on our cvs tree.

I am starting to realize that, perhaps, I should take a directory based
approach to helices' cvs tree.

I have not settled on any particular structure.  However, I am wondering
about several things:

[1] Should I have separate trees for different underlying versions of
net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
building and committing both v4.2.5 and the totally different
distribution v5.x.  So, one line of thinking is like this:

devel/helices/net-snmp/v4.2.4/netsnmp.lrp
devel/helices/net-snmp/v4.2.4/netsnmpd.lrp
devel/helices/net-snmp/v4.2.4/nettrapd.lrp
devel/helices/net-snmp/v4.2.5/netsnmp.lrp
devel/helices/net-snmp/v4.2.5/netsnmpd.lrp
devel/helices/net-snmp/v4.2.5/nettrapd.lrp
devel/helices/net-snmp/v5.0.2/netsnmp.lrp
devel/helices/net-snmp/v5.0.2/netsnmpd.lrp
devel/helices/net-snmp/v5.0.2/nettrapd.lrp
. . .

[2] Perhaps, my net-snmp package, for instance, should be in cvs in
expanded form, so that when only one (1) or a few file contents change,
that will be directly reflected in cvs?  Under this scenario, when only
a single file -- perhaps, the primary binary? -- is changed, users can
checkout only that file.

[3] Item [2] presents a difficulty when a user wants the whole LRP
package as one (1) LRP file.  Is there some way to properly archive and
compress a cvs directory tree and check that out?

[4] I am still confused on how best to handle package descriptions. 
 presents several
TXT files that, once clicked on, present descriptive text regarding the
LRP's that reside in versioned directories below this one.  Another
example is Jacques Nilo's 
wonderful page that links to installation and troubleshooting
information.  How are we to do this under cvs?

What do you think?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS Structure Update

[Mike Noyes]

At 2002-01-07 11:07 +0100, Ewald Wasscher wrote:
>Mike Noyes wrote:
>>The last thing I did before disappearing for the last couple of months, 
>>was to restructure our CVS repository. All developers now have a personal 
>>tree in devel/yourname. There is a bin directory for released files. The 
>>oxygen and dachstein trees are controlled by David and Charles 
>>respectively. Please notify them before committing/adding anything to 
>>those trees. I will create a bin/packages directory for us too. The doc 
>>tree is self explanatory. The src tree structure is pending (consensus 
>>required).
>
>Is there ever going to be any consensus? The issue seems to have been 
>forgotten lately. I might set up my personal cvs tree, but I'd rather not 
>do so.

Ewald,
Thanks for the comments. The personal devel/yourname cvs trees are 
necessary. We must migrate most of the images, kernel tarballs, and 
packages from the shell server into cvs. SF project allocation of resources 
is the main reason for this change. Our space on the shell server is 
limited to approximately 1G, while cvs space is unlimited. We are already 
using over 1G.

I'm working on a way to do daily exports (using cron) of certain 
directories from our cvs repository to our pub directory on the shell 
server. This will allow us to automate the process of keeping those 
directories current. Here are the trees I have in mind: dachstein, oxygen, 
doc, images, packages. All of these except doc are from the bin tree in 
cvs. see

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/

Note: I need to create the images and packages trees in bin. Do I need to 
create a kernel tree also? I plan on using David's scripts for the packages 
tree. see

http://leaf.sourceforge.net/pub/oxygen/repository/

Everyone can keep track of changes made to our cvs repository by 
subscribing to our leaf-cvs-commits list.
http://leaf.sourceforge.net/content.php?menu=14&page_id=20

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS Structure Update

[Ewald Wasscher]

Mike Noyes wrote:

> Everyone,
> The last thing I did before disappearing for the last couple of 
> months, was to restructure our CVS repository. All developers now have 
> a personal tree in devel/yourname. There is a bin directory for 
> released files. The oxygen and dachstein trees are controlled by David 
> and Charles respectively. Please notify them before committing/adding 
> anything to those trees. I will create a bin/packages directory for us 
> too. The doc tree is self explanatory. The src tree structure is 
> pending (consensus required). 

Is there ever going to be any consensus? The issue seems to have been 
forgotten lately. I might set up my personal cvs tree, but I'd rather 
not do so.

>
>
> If you need help with CVS commands please let me know. I'll update the 
> "Individual Developer Content" FAQ in the next couple of weeks.
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/
>
> Any comments or suggestions are welcome.
>
I'll see what I can come up with.

Ewald Wasscher



___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] CVS Structure Update

[Mike Noyes]

Everyone,
The last thing I did before disappearing for the last couple of months, was 
to restructure our CVS repository. All developers now have a personal tree 
in devel/yourname. There is a bin directory for released files. The oxygen 
and dachstein trees are controlled by David and Charles respectively. 
Please notify them before committing/adding anything to those trees. I will 
create a bin/packages directory for us too. The doc tree is self 
explanatory. The src tree structure is pending (consensus required).

If you need help with CVS commands please let me know. I'll update the 
"Individual Developer Content" FAQ in the next couple of weeks.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/

Any comments or suggestions are welcome.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(abouttobe) available.)

[jdnewmil]

On Fri, 20 Apr 2001, Mike Noyes wrote:

> [EMAIL PROTECTED], 2001-04-20 17:26 -0700
> >On Fri, 20 Apr 2001, Mike Noyes wrote:

> > > I thought this might be a good way to write protect hard drives
> > > and flash disks.
> >
> >Perhaps... or it may actually be _too_ restrictive, since you simply
> >don't have the option to write anything to it... almost like a cd,
> >without the media portability.
> 
> Ok. I must be getting confused. I thought packramfs would write temporary 
> data to a cramfs partition.

I overlooked that capability.

> 
> >This seems appropriate for a truly single-purpose hardware device, since
> >you don't need such a big ramdisk, and you don't want to customize
> >it.  When dealing with the variety of hardware that LRP can handle,
> >though, it seems like too much work.
> 
> That would explain the strange look I got from the MontaVista rep. when I 
> suggested cramfs on a floppy. This still doesn't explain why Debian is 
> trying to do the following for their boot floppies.
> 
> http://lists.debian.org/debian-boot-0102/msg00435.html
> ~ Build in crams and ramfs. We're going to boot off of a cramfs initrd
> ~ and then set up and pivot_root into a ramfs filesystem.

I;m not really familiar with the details, but I think the cramfs initrd is
both disk- and ram-efficient, and pivoting the root means switching the
root over to a writeable filesystem while maintaining access to the old
filesystem.  For a boot floppy there is no customization, but it is
convenient to have a writeable root.

---
Jeff NewmillerThe .   .  Go Live...
DCN:<[EMAIL PROTECTED]>Basics: ##.#.   ##.#.  Live Go...
Work:<[EMAIL PROTECTED]>  Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/BatteriesO.O#.   #.O#.  with
/Software/Embedded Controllers)   .OO#.   .OO#.  rocks...2k
---


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)

[Mike Noyes]

[EMAIL PROTECTED], 2001-04-20 17:26 -0700
>On Fri, 20 Apr 2001, Mike Noyes wrote:
> > That doesn't sound good, but how is it different from the backup
> > scripts we use now?
>
>The disk need not be accessed for months at a time in an LRP box.

Jeff,
Understood. Thanks for taking the time to explain this to me.

> > I thought this might be a good way to write protect hard drives
> > and flash disks.
>
>Perhaps... or it may actually be _too_ restrictive, since you simply
>don't have the option to write anything to it... almost like a cd,
>without the media portability.

Ok. I must be getting confused. I thought packramfs would write temporary 
data to a cramfs partition.

>This seems appropriate for a truly single-purpose hardware device, since
>you don't need such a big ramdisk, and you don't want to customize
>it.  When dealing with the variety of hardware that LRP can handle,
>though, it seems like too much work.

That would explain the strange look I got from the MontaVista rep. when I 
suggested cramfs on a floppy. This still doesn't explain why Debian is 
trying to do the following for their boot floppies.

http://lists.debian.org/debian-boot-0102/msg00435.html
~ Build in crams and ramfs. We're going to boot off of a cramfs initrd
~ and then set up and pivot_root into a ramfs filesystem.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(abouttobe) available.)

[jdnewmil]

On Fri, 20 Apr 2001, Mike Noyes wrote:

> [EMAIL PROTECTED], 2001-04-20 16:30 -0700
> >On Fri, 20 Apr 2001, Mike Noyes wrote:
> >
> > > David Douthitt, 2001-04-20 16:25 -0500
> > > >I like the long name idea, using VFAT.  The only thing is, VFAT adds
> > > >FAT to the kernel (pun intended :-)  Just how big is this thing?
> > >
> > > Would someone explain to me why we shouldn't use cramfs? I believe it
> > > works with floppies too.
> >
> >This is designed to remain mounted indefinitely, which is appropriate for 
> >flashram, but I feel this is inappropriate for the floppy.
> 
> Jeff,
> That doesn't sound good, but how is it different from the backup scripts we 
> use now?

The disk need not be accessed for months at a time in an LRP box.

> I thought this might be a good way to write protect hard drives 
> and flash disks.

Perhaps... or it may actually be _too_ restrictive, since you simply don't
have the option to write anything to it... almost like a cd, without the
media portability.

This seems appropriate for a truly single-purpose hardware device, since
you don't need such a big ramdisk, and you don't want to customize
it.  When dealing with the variety of hardware that LRP can handle,
though, it seems like too much work.

---
Jeff NewmillerThe .   .  Go Live...
DCN:<[EMAIL PROTECTED]>Basics: ##.#.   ##.#.  Live Go...
Work:<[EMAIL PROTECTED]>  Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/BatteriesO.O#.   #.O#.  with
/Software/Embedded Controllers)   .OO#.   .OO#.  rocks...2k
---


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)

[Mike Noyes]

[EMAIL PROTECTED], 2001-04-20 16:30 -0700
>On Fri, 20 Apr 2001, Mike Noyes wrote:
>
> > David Douthitt, 2001-04-20 16:25 -0500
> > >I like the long name idea, using VFAT.  The only thing is, VFAT adds
> > >FAT to the kernel (pun intended :-)  Just how big is this thing?
> >
> > Would someone explain to me why we shouldn't use cramfs? I believe it
> > works with floppies too.
>
>This is designed to remain mounted indefinitely, which is appropriate for 
>flashram, but I feel this is inappropriate for the floppy.

Jeff,
That doesn't sound good, but how is it different from the backup scripts we 
use now? I thought this might be a good way to write protect hard drives 
and flash disks.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(abouttobe) available.)

[jdnewmil]

On Fri, 20 Apr 2001, Mike Noyes wrote:

> David Douthitt, 2001-04-20 16:25 -0500
> >I like the long name idea, using VFAT.  The only thing is, VFAT adds
> >FAT to the kernel (pun intended :-)  Just how big is this thing?
> 
> Would someone explain to me why we shouldn't use cramfs? I believe it works 
> with floppies too.

This is designed to remain mounted indefinitely, which is appropriate for
flashram, but I feel this is inappropriate for the floppy.

> http://www.linuxdevices.com/articles/AT5214244852.html
> ~ Together, Quinlan reckons that cramfs, ramfs and packramfs comprise an
> ~ "elegant" solution for embedded developers wishing to optimize boot
> ~ time, resource usage and robustness.

---
Jeff NewmillerThe .   .  Go Live...
DCN:<[EMAIL PROTECTED]>Basics: ##.#.   ##.#.  Live Go...
Work:<[EMAIL PROTECTED]>  Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/BatteriesO.O#.   #.O#.  with
/Software/Embedded Controllers)   .OO#.   .OO#.  rocks...2k
---


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)

[Mike Noyes]

David Douthitt, 2001-04-20 16:25 -0500
>I like the long name idea, using VFAT.  The only thing is, VFAT adds
>FAT to the kernel (pun intended :-)  Just how big is this thing?

Would someone explain to me why we shouldn't use cramfs? I believe it works 
with floppies too.

http://www.linuxdevices.com/articles/AT5214244852.html
~ Together, Quinlan reckons that cramfs, ramfs and packramfs comprise an
~ "elegant" solution for embedded developers wishing to optimize boot
~ time, resource usage and robustness.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3 (aboutto be) available.)

[Jack Coates]

Man, I am so swamped. Ladybug needs to be whacked against the new Oxygen
release -- this shouldn't be too big of a deal, since the new Oxygen has
a fair number of the architectural changes I was working on built into
it (only better). So the work at this point is a matter of kernel
customization, removal of the routing-specific stuff, editing of menus,
packaging the applications to be run, and testing.

Let's say it's far from release. I would love to put it in CVS, and
will follow whatever scheme is used by everyone else.
-- 
Jack Coates
Monkeynoodle: It's what's for dinner!

On Fri, 20 Apr 2001, Mike Noyes wrote:


> Jack,
> How close is Ladybug to release? Is it ready for CVS?
>
> Scott,
> I think Echowall should be added to CVS. Do you agree?
>
> --
> Mike Noyes <[EMAIL PROTECTED]>
> http://leaf.sourceforge.net/
>
>
> ___
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/leaf-devel
>


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)

[David Douthitt]

VERY informative, Jeff!  Very much appreciate this new information

[EMAIL PROTECTED] wrote:

> vfat is backward-compatible. Microsoft used reserved features in the FAT
> format to implement its features, and included consistency checks with
> fallback to 8.3 behavior in case an older MSDOS system modifies the FAT
> entries.
> 
> Every floppy you use in Windows is treated as vfat.

Interesting!

> > > * What about DOS diskettes? 1.44M preformatted diskettes?
> >
> > Require a reformat assuming that they aren't already VFAT formatted. Even
> > for the average Windows user formatting a disk isn't difficult.
> 
> What about them? They are vfat.

Well!

> The vfat module happens to support both the long filenames and large disk
> support.

And just how much space does VFAT take up?

> The loader has to know the name. "ldd" gets the loader to divulge the
> name(s) expected by a binary on a full distro.  Might be better to steal
> this technique in the package loader than add a new file to the lrp
> format, though that doesn't help those with the old lrpkg figure out
> their problems.

My biggest concern is that someone on one of the other distributions
(e.g., LRP 2.9.8) will load a package, see a SegFault, and then go ask
why it SegFaults - with the accompanying head-scratching by the
wizards as to why a prepackaged *.lrp would SegFault.

The version idea is the simplest. just query the version and see
if it is xxx(2.1).

I like the long name idea, using VFAT.  The only thing is, VFAT adds
FAT to the kernel (pun intended :-)  Just how big is this thing?

Long names also mean this: someone on an old distribution copies this
*.lrp over, and of course has to shoehorn it into 8.3 - either
deliberately, or via Windows 8.3 mangling for DOS FAT.  Then loading
the package will fail, because the name doesn't match the .list
name  And using VFAT would allow longer names under UNIX as well.

___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)

[jdnewmil]

On Fri, 20 Apr 2001, George Metz wrote:

> On Fri, 20 Apr 2001, David Douthitt wrote:
> 
> > Not a bad idea; however, there are a few things that come to mind:
> >
> > * How do you create a VFAT diskette under Windows?  Some may laugh; I
> > for one am not sure how
> 
> Beats me. I think it's a simple matter of formatting under Windows. I'll
> give it a shot tonight.

vfat is backward-compatible. Microsoft used reserved features in the FAT
format to implement its features, and included consistency checks with
fallback to 8.3 behavior in case an older MSDOS system modifies the FAT
entries.

Every floppy you use in Windows is treated as vfat.

> 
> > * What about DOS diskettes? 1.44M preformatted diskettes?
> 
> Require a reformat assuming that they aren't already VFAT formatted. Even
> for the average Windows user formatting a disk isn't difficult.

What about them? They are vfat.

> > * What of mkfs.msdos?  Does it understand VFAT?
> 
> Yep. 'mkdosfs -F 32 /dev/fd0[u]' does the trick.

vfat != fat32

The vfat module happens to support both the long filenames and large disk
support.

> 
> > > Why not change the package format?  It's possible to work with deb and rpm
> > > pacakges in shell-script using nothing more than dd, gzip, cat, and tar.
> >
> > So I've heard; however, RPM files have not worked that way in my
> > experience - they require rpm2cpio to get anything decent out.  Also,
> > last time I started untarring (more recent) DEB files there was always
> > an error or warning about a particular file - it may have been called
> > '-' or something.
> 
> I'm also against moving away from text-and-script-controlled tarballs.
> About the only thing that might compel me to want to do so is the ability
> to add apt-get for LRP, with a package repository on Sourceforge to allow
> people to auto-update - and even then, I might need some arm-twisting.
> "Keep It Simple, 'cause they're Stupid" my History teacher always used to
> say.
> 
> > > and I think we could
> > > have minimal dependancy checking (for library existance/version, kernel rev,
> > > etc) without too much bloat to the packaging scripts...
> >
> > How to check for library version?  You could use:
> >
> > LIBC=$(ls -1 /lib/libc-*)
> > LIBC=${LIBC%%.so}
> > LIBC=${LIBC##*/libc-}
> >
> > ...but then you are relying on the name to be correct.  Is it?

The loader has to know the name. "ldd" gets the loader to divulge the
name(s) expected by a binary on a full distro.  Might be better to steal
this technique in the package loader than add a new file to the lrp
format, though that doesn't help those with the old lrpkg figure out
their problems.

[...]

---
Jeff NewmillerThe .   .  Go Live...
DCN:<[EMAIL PROTECTED]>Basics: ##.#.   ##.#.  Live Go...
Work:<[EMAIL PROTECTED]>  Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/BatteriesO.O#.   #.O#.  with
/Software/Embedded Controllers)   .OO#.   .OO#.  rocks...2k
---


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)

[George Metz]

On Fri, 20 Apr 2001, David Douthitt wrote:

> Not a bad idea; however, there are a few things that come to mind:
>
> * How do you create a VFAT diskette under Windows?  Some may laugh; I
> for one am not sure how

Beats me. I think it's a simple matter of formatting under Windows. I'll
give it a shot tonight.

> * What about DOS diskettes? 1.44M preformatted diskettes?

Require a reformat assuming that they aren't already VFAT formatted. Even
for the average Windows user formatting a disk isn't difficult.

> * What of mkfs.msdos?  Does it understand VFAT?

Yep. 'mkdosfs -F 32 /dev/fd0[u]' does the trick.

> > Why not change the package format?  It's possible to work with deb and rpm
> > pacakges in shell-script using nothing more than dd, gzip, cat, and tar.
>
> So I've heard; however, RPM files have not worked that way in my
> experience - they require rpm2cpio to get anything decent out.  Also,
> last time I started untarring (more recent) DEB files there was always
> an error or warning about a particular file - it may have been called
> '-' or something.

I'm also against moving away from text-and-script-controlled tarballs.
About the only thing that might compel me to want to do so is the ability
to add apt-get for LRP, with a package repository on Sourceforge to allow
people to auto-update - and even then, I might need some arm-twisting.
"Keep It Simple, 'cause they're Stupid" my History teacher always used to
say.

> > and I think we could
> > have minimal dependancy checking (for library existance/version, kernel rev,
> > etc) without too much bloat to the packaging scripts...
>
> How to check for library version?  You could use:
>
> LIBC=$(ls -1 /lib/libc-*)
> LIBC=${LIBC%%.so}
> LIBC=${LIBC##*/libc-}
>
> ...but then you are relying on the name to be correct.  Is it?

I don't know about you, but I didn't do anything to the names when I put
together my 2.1.3 modules. On LRP 2.9.8, I get the following:

Veil# ls -1 /lib/libc-*
/lib/libc-2.0.7.so

At that point it's simply a matter of a naming convention. Anyone who's
making images that mess with the libs should be aware that libc NEEDS to
be named that for packages to work correctly.

> For the kernel, you'd probably be best with
>
> KERNEL=$(uname -r)
> KERNEL=${KERNEL%%-*}
>
> ...this assumes that uname -r works; does it?

It does:

Veil# uname -r
2.2.18
Veil#

--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]

"We know what deterrence was with 'mutually assured destruction' during
the Cold War. But what is deterrence in information warfare?" -- Brigadier
General Douglas Richardson, USAF, Commander - Space Warfare Center


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure

[Mike Noyes]

David Douthitt, 2001-04-20 11:24 -0500
>I've had it up to here with all the different package formats - and
>none of them satisfy the above requirement.  I've HP-UX boxes here
>(Software Depots), Unixware ("Packages"), Red Hat Linux (RPM), and
>until recently Debian (DEB).  Makes me want to do what I've heard
>somewhere that a few others are doing: skip the packages altogether
>and only use source *.tar.gz files from the original creator

David,
Midori is using *.tar.gz for their packages.

This reminds me. At the embedded conference, I asked the embedded Linux 
distribution vendors about their support for floppies and generic images. 
The only two that support both are HardHat Linux and Midori. So, the only 
currently available bases for us are LRP(heavily 
modified)/Oxygen/EigerStein(updated), HardHat, and Midori. HardHat uses rpm 
with a stripping script, and Midori uses *.tar.gz.

There were a couple of other interesting things I learned. Lineo, is 
producing a router (hardware+software) based on Linux 2.0.x. It isn't 
certified, but the price point for the low end version is ~$100. None of 
the hardware vendors had SBCs with three ethernet ports. Although, many of 
them indicated this was something they planed on delivering soon. Joining 
the ELC may be a good idea. They had a presentation booth that was 
available for members to show their products/projects. It was empty most of 
the time, so availability isn't a problem. I appears to me that  the first 
thing every embedded distribution produces is a router. I had some 
conversations on the advantages of real-time for QoS also. Opinions were split.

Ray and I did get together and talk. :)
He probably has greater insight into the significant things that happened.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about to be) available.)

[Charles Steinkuehler]

> > If so, I
> > think a separate tree for packages is in order. I also, like David's
diff
> > idea for them.
>
> This doesn't necessarily help in this case, though: the distributions
> now present are starting to show direct incompatabilities:
>
> * glibc 2.0.7 vs. glibc 2.1.3 vs. glibc 2.2 (future)
> * Linux 2.0 vs Linux 2.2 vs Linux 2.4
>
> What the diff file does is to allow a user to get an unmodified source
> tar-ball, and apply the patch to it.  It also means that it puts into
> one place all the work we do to get the source compiled, and it is
> saved and reproduceable.  Some of the reasons I wanted to use diffs
> are: a) creates a package DURING THE MAKE process; b) be able to
> remove the source directory tree in favor of the source file and a
> diff file.  This models after the Debian and Red Hat way of doing
> things; Debian puts out the source tarball and the diff next to each
> other in their source directory; Red Hat puts everything together
> (source tarball, patches, etc) together into a source RPM.



> I'm still contemplating how to create packages that work under glibc
> 2.1.3 and MARK themselves as such.  Perhaps this is a problem which
> should be discussed..



> Red Hat and Mandrake and others put things like versions, CPU, release
> version, into their names.  With the 8.3 limitation imposed by LRP,
> the package names for us don't have that kind of room.



> These are the things I've thought about, and my opinions on them:
>
> * Include versions in the package name - not enough name space.

Why not require VFAT support?  I don't think it adds too much size to a
compressed kernel.  We could also switch to minix formatted floppies, but
the Windows folks would have a fit (and you thought 1680K floppies were hard
to work with on 'Doze :)

> * Include a file (flag) such as: /var/lib/lrpkg/.glibc-2.1
> * Add "(2.1)" to the version, in the .version file, like so:
> 3.61(2.1)-1
> * Use a different extension than ".lrp" - the new Oxygen, using glibc
> 2.1, is not limited to using *.lrp - but this is not true of other
> distributions
>
> I tend to lean towards the latter two, at least for glibc 2.1
> binaries.  The reasons are:
>
> * Someone has to CHANGE the extension to use them - this right away
> tells them something is different.
> * When listing versions, the "(2.1)" stands out more than the
> others...
> * Of course, then there is always the SegFault :O

Why not change the package format?  It's possible to work with deb and rpm
pacakges in shell-script using nothing more than dd, gzip, cat, and tar.
Using dd to cut the file up, you can have an initial text (or script)
portion, followed by one or more tgz archives (this is pretty much how a deb
package is made).

I'd like to see pre/post install/remove script support, and I think we could
have minimal dependancy checking (for library existance/version, kernel rev,
etc) without too much bloat to the packaging scripts...

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about to be) available.)

[David Douthitt]

Charles Steinkuehler wrote:

> > These are the things I've thought about, and my opinions on them:
> >
> > * Include versions in the package name - not enough name space.
> 
> Why not require VFAT support?  I don't think it adds too much size to a
> compressed kernel.

Not a bad idea; however, there are a few things that come to mind:

* How do you create a VFAT diskette under Windows?  Some may laugh; I
for one am not sure how
* What about DOS diskettes? 1.44M preformatted diskettes?
* What of mkfs.msdos?  Does it understand VFAT?

> We could also switch to minix formatted floppies, but
> the Windows folks would have a fit (and you thought 1680K floppies were hard
> to work with on 'Doze :)

Heh.

> Why not change the package format?  It's possible to work with deb and rpm
> pacakges in shell-script using nothing more than dd, gzip, cat, and tar.

So I've heard; however, RPM files have not worked that way in my
experience - they require rpm2cpio to get anything decent out.  Also,
last time I started untarring (more recent) DEB files there was always
an error or warning about a particular file - it may have been called
'-' or something.

> Using dd to cut the file up, you can have an initial text (or script)
> portion, followed by one or more tgz archives (this is pretty much how a deb
> package is made).

I'm not sure what you mean, but I have a strong aversion to any format
which can't be undone by the following GNU tar command:

tar xzvf 

I've had it up to here with all the different package formats - and
none of them satisfy the above requirement.  I've HP-UX boxes here
(Software Depots), Unixware ("Packages"), Red Hat Linux (RPM), and
until recently Debian (DEB).  Makes me want to do what I've heard
somewhere that a few others are doing: skip the packages altogether
and only use source *.tar.gz files from the original creator

> I'd like to see pre/post install/remove script support,

var/lib/lrpkg/.sh

...used this way:

pkg.sh postremove
pkg.sh preremove
pkg.sh postinstall
pkg.sh preinstall

> and I think we could
> have minimal dependancy checking (for library existance/version, kernel rev,
> etc) without too much bloat to the packaging scripts...

How to check for library version?  You could use:

LIBC=$(ls -1 /lib/libc-*)
LIBC=${LIBC%%.so}
LIBC=${LIBC##*/libc-}

...but then you are relying on the name to be correct.  Is it?

For the kernel, you'd probably be best with

KERNEL=$(uname -r)
KERNEL=${KERNEL%%-*}

...this assumes that uname -r works; does it?

___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3 (about to be) available.)

[Charles Steinkuehler]

> Getting back to your CVS comments from yesterday. I agree, we need to
start
> committing files to CVS. There are approximately six people working
> independently on the EigerStein update. Putting these individual pieces
> into CVS will allow all of us to build off of each others efforts.
>
> First, Charles this looks like a significant update. Are we still going to
> call it EigerStein, or have you decided on a new name?

Depends on what you're talking about (see next answer, below)

After consulting my wife (a professional gardner), I intend to use her
suggestion of 'Quercus' (latin for Oak) as a 'family' name.  The initial and
subsequent releases would be named for a particular varieties of Oak:

Quercus macrocarpa - Burr Oak
Quercus rubra - Red Oak
Quercus alba - White Oak

and so on, with subsequent major releases using a different species (like
Maple, Spruce, etc).  The latin and english names could be used somewhat
interchangably...

> Second, are we creating a release that branches from 2.9.8, or ESb2?

There are two issues at hand.  One is an update of ES2Beta, which should
simply be the existing ES2Beta + David's updated binaries for various
libraries and programs that had security holes + latest versions of the
encluded LRP packages + possibly a new kernel.  This should probably be ES3
or something...

I'd also like to see a whole new distribution put together, as previously
discussed.  This would use SeaWall (or one of the other firewall packages)
for the firewall rules, might be based on a 2.4 kernel and perhaps even an
updated libc.  I don't think it matters much what distribution we base this
off of (unless Butterfly actually appears and looks suitable), as long as we
either pick a distribution to develop on, select a distribution that already
squeezes packages for an embedded environemnt (unlikely to solve all our
problems), or (preferred) build a compile environment that can be installed
on any generic linux system, complete with local libraries, so it won't
matter what's running on the development box.

We would, however, need to decide on a general filesystem layout, rc.d
standards, and the like.  Ideally, this layout would match a mainstream
distribution (like debian, redhat, caldera, or similar), so folks wouldn't
be quite so lost when trying to figure out how everything ties together, and
creating packages would likely be easier (I'm envisioning taking an RPM or
DEB, applying a few 'tweaks', and making an LRP or it's new equivelant).

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about to be) available.)

[Mike Noyes]

David Douthitt, 2001-04-20 10:22 -0500
> > How close are you to committing the Oxygen devel tree to CVS?
>
>The CDROM contains a direct image of the Oxygen development source
>tree, along with the packages.  Everything in src/base is either a
>binary in the system or a package on the boot disk.  Everything else
>in src/ other than src/base are package sources; pkgs/ contains the
>results of compilations.
>
>Doing this should set up a good CVS tree for Oxygen:
>
># cd $CVSROOTDIR
># mkdir -p ./mnt
># mkdir -p ./Oxygen
># mount -o loop Oxygen-2.1.3-CDROM.iso ./mnt
># cp -a ./mnt/src/base ./Oxygen
>
>Is this possible on SourceForge?  Also, to get packages, do:

David,
No for two reasons. One we don't have shell level access to our CVS 
repository yet. Second, mount is restricted to root on shell1 (I just 
checked). However, you can commit this tree to our CVS repository from your 
machine. I don't know how long it will take.

># cd $CVSROOTDIR
># mkdir -p ./mnt
># mkdir -p ./packages
># mount -o loop Oxygen-2.1.3-CDROM.iso ./mnt
># cp -a ./mnt/src/* ./packages
># rm -rf ./packages/base
>
>That should do it.

Unfortunately, not. You need to use CVS for the import process. Otherwise, 
it wont be able to setup its internal housekeeping files.

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about to be) available.)

[David Douthitt]

Mike Noyes wrote:

> Third, does anyone have suggestions for the tree structure?

Didn't we already hash that out?

I like separate directories or CVS trees for each of the significant
distributions (base).  Packages should probably be separate the
only interesting complication is that some systems may incorporate
into their base what others use as a package; however, this could be
handled by ignoring the package if the distribution contains the
binaries in the root.  In this case, the distribution would contain
the sources within its own tree, not the package tree.

Thus it would look like this:

++ Oxygen
 |
 + EigerSteinBeta
 |
 + Packages + Network
|
+ System
:
:

...and so on.

> Fourth, we need to decide if packages should have their own tree.

I think they should.

> Are we
> going to try to make them work on as many releases as possible?

I think they should.

> If so, I
> think a separate tree for packages is in order. I also, like David's diff
> idea for them.

This doesn't necessarily help in this case, though: the distributions
now present are starting to show direct incompatabilities:

* glibc 2.0.7 vs. glibc 2.1.3 vs. glibc 2.2 (future)
* Linux 2.0 vs Linux 2.2 vs Linux 2.4

What the diff file does is to allow a user to get an unmodified source
tar-ball, and apply the patch to it.  It also means that it puts into
one place all the work we do to get the source compiled, and it is
saved and reproduceable.  Some of the reasons I wanted to use diffs
are: a) creates a package DURING THE MAKE process; b) be able to
remove the source directory tree in favor of the source file and a
diff file.  This models after the Debian and Red Hat way of doing
things; Debian puts out the source tarball and the diff next to each
other in their source directory; Red Hat puts everything together
(source tarball, patches, etc) together into a source RPM.

I'm still contemplating how to create packages that work under glibc
2.1.3 and MARK themselves as such.  Perhaps this is a problem which
should be discussed..

Red Hat and Mandrake and others put things like versions, CPU, release
version, into their names.  With the 8.3 limitation imposed by LRP,
the package names for us don't have that kind of room.

These are the things I've thought about, and my opinions on them:

* Include versions in the package name - not enough name space.
* Include a file (flag) such as: /var/lib/lrpkg/.glibc-2.1
* Add "(2.1)" to the version, in the .version file, like so:
3.61(2.1)-1
* Use a different extension than ".lrp" - the new Oxygen, using glibc
2.1, is not limited to using *.lrp - but this is not true of other
distributions

I tend to lean towards the latter two, at least for glibc 2.1
binaries.  The reasons are:

* Someone has to CHANGE the extension to use them - this right away
tells them something is different.
* When listing versions, the "(2.1)" stands out more than the
others...
* Of course, then there is always the SegFault :O

> How close are you to committing the Oxygen devel tree to CVS?

The CDROM contains a direct image of the Oxygen development source
tree, along with the packages.  Everything in src/base is either a
binary in the system or a package on the boot disk.  Everything else
in src/ other than src/base are package sources; pkgs/ contains the
results of compilations.

Doing this should set up a good CVS tree for Oxygen:

# cd $CVSROOTDIR
# mkdir -p ./mnt
# mkdir -p ./Oxygen
# mount -o loop Oxygen-2.1.3-CDROM.iso ./mnt
# cp -a ./mnt/src/base ./Oxygen

Is this possible on SourceForge?  Also, to get packages, do:

# cd $CVSROOTDIR
# mkdir -p ./mnt
# mkdir -p ./packages
# mount -o loop Oxygen-2.1.3-CDROM.iso ./mnt
# cp -a ./mnt/src/* ./packages
# rm -rf ./packages/base

That should do it.

___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3 (about to be) available.)

[Mike Noyes]

Charles Steinkuehler, 2001-04-20 08:45 -0500
>It'd be interesting to see how much each option affected size, but
>overall a 411K 2.4 kernel is VERY COOL, and should be quite usable for
>floppy firewalls.  While I'd like to see a 'one size fits all' kernel,
>perhaps there could be a floppy only, minimal kernel, and a larger
>kernel with all the 'goodies' like RAID, loopback, etc (compiled as
>modules, where possible) for folks running from CD, HDD, Flash, or what
>have you.

Charles,
This sounds good.

Getting back to your CVS comments from yesterday. I agree, we need to start 
committing files to CVS. There are approximately six people working 
independently on the EigerStein update. Putting these individual pieces 
into CVS will allow all of us to build off of each others efforts.

First, Charles this looks like a significant update. Are we still going to 
call it EigerStein, or have you decided on a new name?

Second, are we creating a release that branches from 2.9.8, or ESb2?

Third, does anyone have suggestions for the tree structure? Should we use 
Dave C.'s or Matthew Grant's devel snapshot as a template? I did the 
following search on Google looking for ideas.
http://www.google.com/search?q=cvs+repository+structure

Fourth, we need to decide if packages should have their own tree. Are we 
going to try to make them work on as many releases as possible? If so, I 
think a separate tree for packages is in order. I also, like David's diff 
idea for them.
https://sourceforge.net/tracker/index.php? \
func=detail&aid=412704&group_id=13751&atid=313751

David,
How close are you to committing the Oxygen devel tree to CVS?

Jack,
How close is Ladybug to release? Is it ready for CVS?

Scott,
I think Echowall should be added to CVS. Do you agree?

--
Mike Noyes <[EMAIL PROTECTED]>
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel