[pacman-dev] PATHNAME in sync/*/desc
markc at renta.net
Wed Mar 12 00:52:43 EDT 2008
On Wednesday 12 March 2008 08:36:16 Dan McGee wrote:
> > Would it be feasible to add a %PATHNAME% variable to the sync desc file ?
> > For instance in this case, fetching "any" arch packages would not need to
> > symlinked into the same directory to be found...
> > %FILENAME%
> > hotstuff-0.9.2-1-any.pkg.tar.bz2
> > %PATHNAME%
> > ../any/
> Not a huge fan of this behavior, as I really like the current scenario
> where the DB always lives with the packages.
One added complexity, that is currently available, is having
symlinks to packages outside of the current directory so, in a
way, the DB does not always live with the packages. The symlinks
remain in the same directory but not the actual packages. To me,
this *may* be clarified better by having the path component
explicitly noted in the DB itself rather than implied by an
external filesystem symlink. Maybe.
> It greatly simplifies the
> need for repo-add to do anything funny with the paths, as we just know
> to always add the basename of the file. That would need to be
> addressed if we added this functionality- how would you add relative
> paths using repo-add?
Well I just tried this below but the resulting package could not
be found and the local sync DB showed no sign of including the path...
repo-add my.db.tar.gz *.pkg.* ../any/*.pkg.*
so I thought/hoped it might do as Aaron suggested and end up with
a full relative path but it didn't when I checked the local sync
DB entry for the packages in ../any/.
> Would it generate the relative path on its own
> (possibly traversing out of webserver accessible directories which
> will break your repository),
I would think this relative path is matched to the remote DB and
would not get added if it could't be found at the time repo-add
is invoked. It would be assumed the same layout, as stated in the
DB, would exist in reality regardless of how the whole repo is
copied or mirrored.
> or would you have to specify an
> additional path? What if I build my DB in one place, but serve it in
> another (something I actually do)?
I rsync my local repo to a remote live server and in this case
there would be no problem that I can forsee.
> We haven't even begun to talk about
> deltas and where they should live.
They're just more file components that could follow the same
relative patch agenda.
> This came up when Xavier and I were
> researching the delta creation being done in repo-add.
> Of course, I see the advantages this could offer with the -any
> packages, I just wanted to get my two cents in from the other side.
Sure, as is any change worth the tradeoff between added benefit
or possible breakage.
On the PATHNAME = URL idea, I could imagine this could also be
useful, if at all possible, because I could offload some packages
to a variety of other backend servers according to demand. I could
have the DBs hosted on a server with limited bandwidth but high
availability and offload some or all of the packages to another
server with a higher and/or cheaper bandwidth quota. I could
perhaps use Amazon S3 cloud for important popular packages and a
Dreamhost cheapie account for less popular packages, all from
the same repo sync DB.
I'm not suggesting this idea has any high yield benefits but if
it were available then I could imagine taking advantage of it.
However, I suspect bittorenting packages would probably have the
best impact on distribution load. Better still, if it were possible
to "capture" what would be otherwise transferred via an rsync update
to a local binary blob diff (for the whole archive, or per repo
section) and use bittorent technology to transfer that blob and
patch the other end in one go.
More information about the pacman-dev