[packagers] Distributing the product

David Hrbáč david-lists at hrbac.cz
Mon Apr 18 19:23:21 CEST 2011


Dne 18.4.2011 17:18, Dag Wieers napsal(a):
> I agree, although I would keep el2.1 packages for the time being. The
> question is whether we want to keep th eold package somewhere in a
> publically accessible vault, or not. Maybe el2.1 belongs there.

I plan to have archive.rpmforge.org for the obsolete folders, including 2.1.

>
> Repoview in the past was very expensive to create, but if we drop APT
> metadata, and only offer 1 metadata per repository this would be
> possible. Still I would so love to have a one-pass tool that generates
> both metadata and interface.
One pass tools is available. Bash script:
echo "Reporeload processing..."
repodata=("hrb" "hrb-tls" "hrb-bacula" "hrb-fw" "hrb-kernel" "hrb-ssh"
"hrb-as")

for index in ${!repodata[*]}
do
  printf "%4d: %s\n" $index ${repodata[$index]}

  for a in `find /var/www/html/hrb33/el4/${repodata[$index]}/ -mindepth
2 -maxdepth 2 -type d`
  do
    if [ ${repodata[$index]} == "hrb-kernel" ]; then
      repomanage -k 5 -o $a | xargs rm -f
    fi
#    createrepo -q --skip-stat --update -d -c /tmp/repocache $a
    createrepo -q --update -d -c /tmp/repocache $a
    repoview $a -q -t 'David Hrbac' -f -u
http://fs12.vsb.cz${a#/var/www/html} -k /usr/share/repoview/hrb/ -f
  done
  for a in `find /var/www/html/hrb33/el5/${repodata[$index]}/ -mindepth
2 -maxdepth 2 -type d`
  do
   if [ ${repodata[$index]} == "hrb-kernel" ]; then
     repomanage -k 5 -o $a | xargs rm -f
   fi
   #repomanage -k 5 -o $a
#   createrepo -q --skip-stat --update -d -c /tmp/repocache $a
   createrepo -q --update -d -c /tmp/repocache $a
   repoview $a -q -t 'David Hrbac' -f -u
http://fs12.vsb.cz${a#/var/www/html} -k /usr/share/repoview/hrb/ -f
  done
done

steps:
1. remove every instance but last 5 per package
2. create repository, using repo cache (huge speed up)
3. create repoview
 
>
> On the other hand, having a dynamic web-interface that allows to
> browse/search the repository metadata would be prefered over a static
> repoview. For one, it does not have to be mirrored !!
Repoview is good enough. If we mirror it, that it will exactly
correspond to this particular mirror repo.
>
> Yes, but surya is RHEL4. Karanbir mentioned that he now can do sqlite
> on RHEL4, but it is currently still not possible. Either we move to
> another system, or we need Karanbir's solution.
>
This is something Karanbir has been asking the info from me. As I have
written. You can still have surya, as the primary source repository
source. This signed repo tree might be mirrored to main mirror, where we
can run sqlite createrepo etc. I can prepare machine as main
mirror/archive storage. We have planty of virtual resources :o). This
machine can than prepare (semi)dynamic mirror list/metalink list for yum.
>
> These mirrors are collected once by using Google. Instead of having a
> list of people that mirror it, we should be having a mailinglist and
> actively communicate with mirror admins. In fact, they should be part
> of this discussion before we redesign the repositories.

Yes, there's a task:
- create mirror maillist  :o)

Well, I guess there is no need to discuss the repo with mirror admins.
We have to just stick with standards, that's all.
>
> There is one thing that I would like to bring into this discussion. I
> very much like the packages.sw.be interface. In fact I often use this
> at customers for downloading a specific package for a specific
> distribution.
>

I'm fine with it, this is something the mirror SIG is not interested in
right now. On the other hand I need to keep SRPMs folder across repos
and archs, just like we are having now. I'm creating local repo of it,
I'm using it as a source for upstream release checking:
root at specs2:1292:291:~/hrbcnu$ python cnucnu.py  --create-bugs -v
1/91 * altermime Added cnucnu-FedoraRawhide repo from
http:/repository.vsb.cz  
6/91 * chkrootkit
cnucnu.errors.UpstreamVersionRetrievalError                  
11/91 * iftop: repo=0.17
upstream=1.0pre1                                      
12/91 * lha
cnucnu.errors.UpstreamVersionRetrievalError                        
19/91 * nmon
cnucnu.errors.UpstreamVersionRetrievalError                       
21/91 * p7zip: repo=9.13
upstream=9.20.1                                       
35/91 * perl-Data-Dumper-Concise: repo=1.100
upstream=2.020                    
36/91 * perl-Digest-MD5: repo=2.39
upstream=2.51                               
37/91 * perl-Digest-SHA: repo=5.50
upstream=5.61                               
61/91 * perl-Math-BigInt-FastCalc: repo=0.19
upstream=0.28                     
69/91 * perl-Pod-Simple: repo=3.15
upstream=3.16                               
74/91 * perl-Unix-PID: repo=0.0.15
upstream=0.23                               
79/91 * phpmyadmin3
exceptions.KeyError                                        
80/91 * proftpd
cnucnu.errors.UpstreamVersionRetrievalError                    
81/91 * razor-agents: repo=2.84
upstream=2.85                                  
86/91 * subversion: repo=1.6.15
upstream=1.6.16                                
89/91 * unarj: repo=2.63
upstream=2.63a                                        
91/91 * zoo
cnucnu.errors.UpstreamVersionRetrievalError                        
                                                                               

==================== Results ====================
Total                    91 (100%)
Outdated                 11 ( 12%)
Unresolved                6 (  6%)


> I would like to keep this structure, in fact, it is the base structure
> used for creating everything else. The question begs if we want
> mirrors to also mirror this structure (probably not) or whether we
> want a dynamic webinterface provide this exact view (possible thanks
> to SRPM Id).
No, we don't. We also don't need some dynamic web. Let's start with
simple and working solutions. We can improve later.
DH



More information about the packagers mailing list