[pacman-dev] Things to iron out

[Judd Vinet]

On Mon, 16 Oct 2006 16:31:53 -0500
"Aaron Griffin" <aaronmgriffin at gmail.com> wrote:
> ** -$ARCH package name suffix - do we want this? How should we handle
> backwards compatability if we do move to this scheme?

I'm fine with adding an arch suffix, as there seems to be good
arguments to do so.  Though only useful for -A/-U operations, they're
probably handy for developers and 64-bit users who juggle 32- and
64-bit packages.

As for backwards compatibility, can we fallback to using the "arch ="
line in .PKGINFO if the suffix isn't present?

> ** SHA1 vs MD5 - opinions/views on this? I know frugalware seems to
> like sha1, but md5 is the defacto file-validation mechanism (if only
> for checking if the download is uncorrupted).  As Juergen brought up
> on the arch-dev ML: md5 may be easy to collide when dealing with
> something like ps files that contain hidden data, but binary files,
> like .gz files, are very difficult to find collisions for.

I never pretended that md5 was for anything security-related.  If we
were trying for security, we would've gone straight to signed
packages.  The md5sum was added to make sure downloaded files weren't
corrupt.

I don't see the point of SHA1 if we're still using it/them for download
validation.  If we want security, then we might as well do it right.

> ** Version number - Frugalware is currently at 3.4.X, while we haven't
> released a single 3.0 release - how should we handle this?  Jump right
> into 3.5 ?

Hmmm... It'd sure be nice to stay in sync with FW, but it is weird
starting at ~3.5.0.  There would be some initial confusion, but nothing
major -- there are other packages that increment the versions steadily
before making any real releases.

I'd vote for the sync over a 3.0 fresh start.

> ** Anything else? I'd like to hear any outstanding issues the
> Frugalware peeps have.

It'd be nice to get a ChangeLog going that has all the main
additions/changes in it.  That way other pacman devs can see what's
been implemented already w/o having to pore through the code itself.
For example, say I wanted to implement the Last-Modified header
checking for HTTP downloads -- it'd be nice to know if that's been done
already or not.  (I think it has, FWIW)

Turning a CVS-generated ChangeLog into one with only the major points
is a big pain in the ass though.  Any suggestions?


- J