Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about to be) available.)
> > 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.)
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.)
> 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.)
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.)
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.)
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
