[pacman-dev] $ARCH suffix on packages

Christian Hamar krics at gds.hu
Tue Oct 10 12:53:47 EDT 2006

> Being that pacman3 will probably be side-by-side installed with
> pacman2 for a bit, while we iron things out, is there a way to smooth
> the transition?  Perhaps a temporary "check for the arch version, if
> not found, try without the arch name" until we can move everything
> over... assuming, of course, that we do move to this scheme.

For backward compatibility. The way what you write down now is fully
walkable :) I mean we did many "non-compatible" patch to pacman. Like,
libarchive, md5->sha1, gzip->bzip2. But we solved compatibility issues
via that way what you wrote here. 

A simple example. At that time we migrated to sha1 then we not rebuild
all of our packages with new pacman. We just hold MD5 field for backward
compatibility and put a new SHA1 field. Packages are created newly got
only SHA1 field in pkginfo and in other places. Packages that still not
rebuilt got MD5 field and not sha1sum. So what i mean. We made a patch
that pacman detect if a package got SHA1 field, then operates with SHA1
funcs. IF MD5 detected (old package, not recompiled) then using MD5
funcs. Same with gzip->bzip2 migration and with libarchive.

So in here as you wrote, i dont think that hard to implement in pacman
that handle -$ARCHS and original packages in same time. Maybe gensync
need some trick. But i think its easy to code this into pacman and be
backward compatible.

Since all of our patches was backward compatible. (only this -$ARCHS one
not made for backward compatible, because when we made that archlinux
does not got any other arch (now it got) )

Second line (not so specific to frugalware :) specific to archlinux ! ):

The pacman2 and pacman3 at same time think a bad idea. As i mentioned
sha1, bzip2, libarchive patchs are all backward compatible and worked
when we upgraded from pacman2 -> pacman3 in frugalware. We not rebuilt
the whole of our packages. There was no such need. By time, new features
integrated automatically into new packages or rebuilded pacakges,
because makepkg was forced to implement new stuffs (eg.: bzip2 packs,
sha1sum, sha1sum in fdb, etc) .

I dont see any point to use pacman2 && pacman3 in same time. But i dont
got rights to made it, because i'm not an archlinux developer :) Of
course this is archlinux releated and archlinux devels need to see whats
the point. 

This was just an idea and a comment about our patches.

Christian Hamar alias krix

More information about the pacman-dev mailing list