Re: Proposed SQL schema rev1

Hunter Matthews wrote:

> On Thu, 2002-01-31 at 18:53, Todd Nemanich wrote:
> 
>>Entities Name(attribute,attribute,...) :
>>
>>-Packages (name, version, release, epoch, 
> 
> You need a string to point to both the rpm on the filesystem and a
> string to point to the header on the filesystem.


Ok. This will be done in package files.


>>-Package_layers (layer_name): 
>>
> 
> I can't see where this would be used at all. "Group"ing of packages in
> RHN is strictly by channel and sub-channel. What feature(s) would this
> support?
> 


Ok, I'll cut this out for now. When I started on 
this thing (about a year ago, when I had free 
time) I was looking at using it to hold enough 
information to build a kickstart file off of, and 
then be able to kickstart off the system itself 
(like ghosting the box). So this was aimed toward 
that end.

> 
>>-Package_files (arch, os, os_version, 
> 
> OH, I see. You seperated the concept of a package from a package file.
> You meant to reduce the number of packages by letting multiple "package
> files" share the same deps/provides, didn't you? 
> 
> Thats a good idea, but tragically won't work. Glibc i586 provides stuff
> that glibc i386 doesn't. 
> 


Grrr.... That sucks. Ok, I'll alter it. That's 
going to cause a little reorganization


> 
>>-Checksums (file, checksum, config): 
> 
> What would this provide? RHN itself never cares what the "interior"
> checksums for a package are. In fact, it lets the network layer worry
> about transmission problems. What feature would this provide?


This can be cut for now. It is aimed to allow 
current to provide a sort of checksumming service, 
which is not part of RHN. Again, this is legacy 
from when I started.


> 
> 
>>-Packager (Name, email, gpg_key): 
> 
> Future. I could see this being useful, but not for the first design
> please.


Cut.



>>
>>
>>Packages(1) <requires> Dependencies(N) : This 

 >>

>>Packages(1) <provides> Provides(N) : These are the 

 >>

>>Dependencies(1) <solved by> Provides(N) 
> 
> Cut both, in the first run.


Really? Ok....


> 
> 
>>Channels(1) <works with> Channels(N) : This allows 
>>
> 
> Perfect. We want to mirror how RHN does it, which is 
>                        P
>                   +----+----+
>                   |    |    |
>                   C    C    C 
> 
> Where a parent channel (P) may have any number of children (C), but no
> child is the parent of anything, and there is no relationship between
> children. (IE, a tree may never have a height of more than 1)


Ok, I'm going to try and get a trigger together to 
enforce this.


>>
>>That is the schema I'm looking at in it's current 
>>form (no pun intended). Additionally, I will be 
>>providing a couple of triggers that can be used to 
>>provide strict dependency checking upon packages 
>>being inserted or added to a channel. The triggers 
>>will be in PgPLSQL.
>>
> 
> Make sure this strictness can be turned on or off - it is often the case
> that you want package trees which are incomplete: IE not every package
> has every dependency satisfied in the tree. This occurs in the real
> world for odd technical or political reasons. 


Perhaps at some point I will have some 
configuration option set within the DB that will 
say if the trigger should be used or not. For now, 
you either use them, or you don't.