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/<pkg>.glibc-2.1
* Add "(2.1)" to the version, in the <pkg>.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
