There are some differences of opinion on some of these things - I'd like to hear developer opinions (especially judd) on the following topics, so we can get a few of these things out of the way: ** -$ARCH package name suffix - do we want this? How should we handle backwards compatability if we do move to this scheme? ** 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. ** 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 ? ** Anything else? I'd like to hear any outstanding issues the Frugalware peeps have. Thanks, Aaron
** 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 ?
You might as well just go straight to version 4.0 ;o) Jason
On Mon, 16 Oct 2006 23:31:53 +0200, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
There are some differences of opinion on some of these things - I'd like to hear developer opinions (especially judd) on the following topics, so we can get a few of these things out of the way:
** -$ARCH package name suffix - do we want this? How should we handle backwards compatability if we do move to this scheme?
** 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.
** 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 ?
Well the package managers won't be excactly the same will they? I mean if you can't guarantee that I think something like this should be posted to main page: We (or maybe you should just say "you", Aaron :)) keeps the frugalware and archlinux pacman in sync but the version numbers are not the same to avoid confusion when archlinux or frugalware pacman differ in implementation due to political disagrement.
** Anything else? I'd like to hear any outstanding issues the Frugalware peeps have.
Thanks, Aaron
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 16 Oct 2006 16:31:53 -0500 "Aaron Griffin" <aaronmgriffin@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
On Mon, Oct 16, 2006 at 07:00:44PM -0700, Judd Vinet <jvinet@zeroflux.org> wrote:
Turning a CVS-generated ChangeLog into one with only the major points is a big pain in the ass though. Any suggestions?
i think the changes from us are mainly documented in a user-readable style in the NEWS file udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
** Anything else? I'd like to hear any outstanding issues the Frugalware peeps have.
Hey. Just a notice again. There is a problem with libarchive when you compile with ACL support on. As i see latest libarchive still NOT got any --disable-acl option and it detects automatically that have ACL on the system or NOT. This is not good for pacman, because if libarchive was linked with ACL (dunno how to detect this from configure.ac :S ) then you need some flags like -lacl for pacman compile :S Which is not the main problem. The main problem that i cant determine how libarchive was compiled. with acl or without acl. This can cause problem on archlinux, because there is no way (at this time) to create packages in a chroot env. At us this is not a main primary problem, because we use chroot and when compiling libarchive / pacman we dont ship ACL packages into it, then libarchive cannot link to ACL. So any suggestion to solve this ? At last we need to detect in pacman's configure.ac that libarchive was linked with ACL or without. If yes put -lacl into FLAGS if not then not put -lacl. Regards Christian Hamar alias krix Hungary Frugalware Development Team
participants (6)
-
Aaron Griffin
-
Christian Hamar alias krix
-
Jason Chu
-
Judd Vinet
-
kfs1＠online.no
-
VMiklos