Re: [leaf-devel] Package Repository

[Greg Morgan]

Matt Schalit wrote:
> Charles Steinkuehler wrote:
>
> > Also, I see room for multiple versions of similar packages, and even
> > different versions of the same package.
>
>
> Hi, I split this off into a new thread just to quickly talk
> about something that's been on my mind for a bit.
>
> *Global Package Repository*
>
> I'll be really sad if we go down the road of multiple versions
> of the same package without a complete overhaul of our system
> for dribbling packages around the website.
>
> If a package works on more than 1 LEAF version, please,
> O' Magnificent Ones, let it be stored in a single global
> package repository.
>
> Somebody is really going to need some help to find all the
> hundred or so packages David D. has tucked away in his devel
> tree. And I won't go into the rest. You all know what it's
> like out there.
>
> It's not fair that we don't do some organization as part of
> our attempt at a new package system!
>
> But what delimits if a package will run on a LEAF version?
> Libc?
>
> Regards,
> Matthew


I had a rather interesting thought about the whole packaging, GUI, database, etc. subject this last week. I wanted to respond with code so I have been quite until the code could speak. However, Matthew's post is exactly what poped into my head on Tuesday or Wednesday last. You see I was thinking that XML was a nice platform independent tool. I want to somehow represent the data model of the database everyone has been talking about. The database is really just an abstraction of what LEAF is.

(LOL..It is such a shame that Microsoft's association with XML has given
it a sour taste in many people's mouth. But I think this is one think
that MS gets. They saw how Java made your code platform indepent. They
understood from this experience how XML could make your data platform
indepentant but with the cost of a few extra tags. Oracle has taken
both of these to heart. One of the coolest tools I have seen is their
Database Configuration assistant, dbca. It has a Java front end and an
XML backend. Tool looks the same on Linux, Sun, and the list goes on.
Port a JVM and you are ready to go. Once you understand XML and see what
the tool generates, it really is quite fasinating.)

So I was thinking how could I show or model some code that would help what vision I am catch about this database and what I believe it can do for the project. My thinking is that it is too early to talk about implementation. I think once the idea of LEAF is abstracted, then we do code. In the fashion of the book "Linux Device Drivers" page two (first edition), I want to focus on the Mechanism not the Policy of who the Mechanism will be used. So I said to myself I use sql tables, insert statements, and sample select statements, more focus could be placed on the issues of what any can of interface will to taken into account. I have presented one idea of how that configuration system could look, but I am really impassioned about what the data needs to look like right now. So much so that I am having trouble turning the old mind of to sleep. ;-)

I started to layout tables in my head while walking to lunch "...oh yeah and Greg you got to get back to Mike Noyes about help on php web site...". Then it hit me, SF provides the project with a mysqldatabase. If I add a few more attributes the database, the global reposity, or whatever you want to call it could be

o A FAQ type thing: What does this variable do?

o Add a URL attribute, where can I locate the package that holds this variable because it will help me do x.

o What are the list of packages that are ready for Bering uCLibc?

o A phpws page could be put over this set of tables because php web site already uses mysql.

o If all the data is collected into a database, then SQL statements can be used to transfore the repository, into XML, a directory structure, name value pairs. All you have to do is drop the attributes that are not required for this answer. This is a place where a SQL select statement excells.

o I am not convinced yet there has to be a major change is required in the packaging system. I am thinking right now all that is required is some code clean up. I am thinking, if all the rigor that is required is pulling the variables to the top of a file to be configured and refine any bash functions in the same file to the bottom. The refining of the functions would be to decouple them more from the variables. Perhaps as Lynn suggested, an external file i.e.

#!/bin/bash
# network.conf
#
#
# common_beginning_sed_target
# variable a
# variable b
# variable ...
# common_ending_sed_target
#
# decoupled_function_a()
# decoupled_function_b()
# decoupled_function_...()
#
# end of file.

If the data model tells me that for package x, I find variable a in network.conf, I can just replace all the variables between the sed targets with their modified values. Here a name value pair file may be easier to point to and modify using the ., source command. (LOL Steady Greg Steady...you're drifting into policy/implementation land.)

o I am excited about this data model because of the potential reuse that it can have. If you allow me to code name the data model Gila Monstor, I can prefix GM to all the tables. There will be no name space collisions in the mysql database shared by phpws. The data model can be used to point users to packages at Lynn pointed out. The data model can point to root.lrp for each distro for example. The data model can point to different flavors of root.lrp for say Dachstein. "Where's the serial console version?" The data model can be transformed into Chad's or Eric's concept. If you have not used SQL before or on a limited basis, this is where I think some examples are required to understand the transformation possibilities. What cannot be done in a SELECT statement can always be taken care of by some well placed sed search and replace tokens.

o As I think about LEAF abstractly in this fashion, a LEAF distro is nothing more than a Master Detail Detail Detail relationship.
Master Table = GMLEAF
Detail Table = GMLEAFPackageList
Detail Table = GMLEAFFile
Detail Table = GMLEAFVariable

Please understand that I don't have all the attributes squared away in my head yet nor the complete design, but try and imagine some of your wish list items and issues in the following. I am just cutting and pasting from an earlier post so I can go to bed. :-) Missing are the ordering of variables and the URL pointers, etc. This XML is at the very heart of the above master, detail, detail, detail relationship. I find XML a very espressive language in this sense. The real "ohh ick" here is not XML, etc. but coming to an abstract model of what LEAF is.

Some examples to think of until I have some working code.
o Greg proposes a new distribution, teton. Insert a row describing teton into Gila Monster LEAF table called GMLEAF.

o Bering uClibc team completes another package. Transform the data rows from regular Bering into uClibc Bering. Adjust the URL attributes or columns to point to the new package location.

o Mike Noyes comes up with this slick phpws page to point to all this information. Moreover, he creates a web page that lets a user configure a distro and download it to their harddrive, etc.

o Chad Carr needs a fresh copy of data for his template system. Chad runs xyz.sql statement.

Hopefully, you can gronk the vision I saw last week. I almost tripped over myself when it came to me this last week. Imagine all the potential problems this whole packaging, configuration, GUI, series of email threads is saying can be solved i.e.
> It's not fair that we don't do some organization as part of
> our attempt at a new package system!

The URL pointers in the table could do this.

>
> But what delimits if a package will run on a LEAF version?

The pointers in the SQL tables delimit this.
SELECT package_name
FROM GMLEAFPackageList
WHERE LEAF_distro = 'Dachstein'
ORDER BY package_name;

> Libc?

SELECT package_name
FROM GMLEAFPackageList
WHERE LEAF_distro = 'Bering uClibc'
ORDER BY package_name;

I am really excited about what can happen here! Sleep? what's that? It is a shame my wife had so many honey dos this weekend. But the old proverb speaks true, "Happy Wife. Happy Life." LOL

Greg Morgan


<GMLEAFPackage>
<Package Name="weblet">
<RequiresPackage Name="" DependancyOrder=""/>
<File Name="weblet.conf" Location="/etc">
<Variable Name="" Type="">
<comment></comment>
<value></value>
</Variable>
</File>
</Package>
<Package Name="nextpackage">
<RequiresPackage Name="libz" DependancyOrder="0"/>
<RequiresPackage Name="libxyz" DependancyOrder="1"/>
<File Name="nextfilename" Location="/etc">
<Variable Name="" Type="">
<comment></comment>
<value></value>
</Variable>
</File>
</Package>
</GMLEAFPackage>





-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

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