seth vidal wrote: >>that would be a funny thing;-) >>may be header.info should contains full url in this case... > > > what does the full url mean? > the baseurl could be relative - think about if someone is proxying or > tunnelling it. What about file:// urls. that's exactly what I'd like to see. full url is the concatenation of the <base> given at the command line argument (if there is no protocol specification then you can assume file://) plus the relative path. in this case you can create a repository even for a remote ftp or webserver: yum-arch ftp://x.y.com/a/b ~/yum-rep/ or even yum-arch ftp://x.y.com/a/b /var/cache/yum/base/ > the reason header.info contains the relative path is b/c that's the only > location we can count on being around - a path directly adjacent to the > headers dir. > > > >>in the conf file: >>-------------------------------- >>[base] >>name=Red Hat Linux $releasever - $basearch - Base >>baseurl=file:///<base>/mirror/redhat/$releasever/ >>-------------------------------- >> >>and run >>yum-arch <base>/mirror/redhat/8.0/ <base>/yum-repository/redhat/8.0/ >>... > > > I'm not sure that's _less_ of a hack than a symlink. > At the moment I'm not sure of a clean way of making sure the headers are > nearby the pkgs and yet still allow for pointing to mirrors easily. they have to be nearby? >>in this case if I decided to mirror another site (eg rh contrib net >>reborn) I just have to add on line to my mirror script and one line to >>my yum repository generator (and I don't have to create a huge link forest). > > > it's ONE link - how is that a link forest? you've got right I can make the link at the top level.. you know here it about midnight...:-( -- Levente http://petition.eurolinux.org/index_html "The only thing worse than not knowing the truth is ruining the bliss of ignorance."
