Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

Bryan Gartner said on Wed, Oct 17, 2007 at 07:52:01PM -0600:

> > The remaining question I have is for the name of the directories.
> > Currently by default they are named /var/log/linuxcoe-sd-base, ...
> > /var/www/linuxcoe-sd-base. I wonder whether it would be cleaner to call
> > those just /var/www/linuxcoe-sd (or even /var/www/linuxcoe) for more
> > clarity on the admin side, and as all packages will add content below.
> > May be solved later on BTW.
> > 
> Actually, my debian packages (which now include base+docs+Distro=FOSS
> ones) all install to the same prefix which is currently
> /usr/share/linuxcoe-sd/4.1 (yes I know you object to the 4.1 portion),
> but the point remains the same (and that issue is still bubbling to
> the top of my todo list).

Same here:

[root@dploy ~]# rpm -ql linuxcoe-sd-base | grep 4.1
/var/cache/linuxcoe-sd/4.1
/var/lib/linuxcoe-sd/4.1
/var/lib/linuxcoe-sd/4.1/profiles
/var/log/linuxcoe-sd/4.1

So I guess this remains to be chosen and solved.
Maybe another variable would be useful for that, that we could use to
create subdirs under /etc, /var/lib, /var/log, ... and in the upstream
version you could still use linuxcoe-sd/4.1, when we could then use in pkg
only linuxcoe-sd (or whatever name we agree upon). Is that what you intended ?

> And I have a vm (distinct from the vm that I build these .debs on) that
> has all of these installed and working. 

Out of curiosity, what VM system are you using ?
Do you use LinuxCOE to deploy them ;-) ?

> FWIW, all of the boot images
> are currently still in CVS in their original location, yet their
> respecitve Makefile.am just doesn't deliver them.  One can still
> obtain the images from:
> 
> 	http://instalinux.com/snapshots/images
> 
> And I'll note that in the README and respective documents when this
> process is complete.

Ok. I'm also far behing in term of docs :-(

However, for non-OSS distro, there is probably a need to still provide
the content somewhere, internaly,as well as the tool to build it from
repository.

> What I was thinking is pretty general, basically have the user supply
> the prefix to a "known" good repository, and then recursively look
> to find the correct kind of files,  then do the "magic" as noted
> in the images/README file.  And for extra credit, remember that the
> repository does not need to reside locally, but could simply be
> a well-known internet mirror ;)  With something like this, whether
> you mirror, use mrepo, or just reference somebody else's repository,
> you would be covered.

Well the design is probably more easy than the code here ;-)
The prefix to a "known" good repository should probably be a URL such as
file://... or http://... or ftp://... but the recursive aspect may then
be difficult to deal with remotely.

I think that 90%+ of the people, will just use an existing/or internal
mirror of the original structure.

So I guess that for, say centos, we will find :

[root@dploy ~]# ls /pub/centos/
2@    3.4@  3.8/  4.1/  4.5/    dostools/       RPM-GPG-KEY-beta RPM-GPG-KEY-CentOS-4@
3@    3.5@  3.9/  4.2/  5/      graphics/       RPM-GPG-KEY-CentOS-2@ RPM-GPG-KEY-CentOS-5
3.1@  3.6@  4@    4.3/  5.0/    HEADER.html     RPM-GPG-KEY-CentOS-3 TIME
3.3@  3.7@  4.0/  4.4/  build/  HEADER.images/  RPM-GPG-KEY-centos4 timestamp.txt

I don't think it makes a big contraint. So having the such a prefix allow
for the script to fetch with wget what is needed and create the local
structure needed for LinuxCOE. Is that what you were proposing ?

(In that case, locally it could be file:///pub/centos and remotely
ftp://deploy/pub/centos)

> > On that one, if you want, I can copy your current content under pbconf,
> > make the adaptations, and you could then test it, once you have a
> > working pb on your side ;-)
> 
> All I have yet to finish are the nonFOSS distro's.  So feel free to
> give it a try with base+one other.

Ok, I made a first copy today of the deb files and have made a rough
adaptation. Not even tested. I'd really like to finish first the rpm
one, as I think making deb after that is just a piece of cake, as you
have the conf ifles, and I'll then have the logic for pb.

> FYI, I think I have a lead on the relaxing automake1.4 dependency and
> am doing some testing now.

Good :-)

Bruno.
-- 
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org