I was messing around with the portarchivetype option today and tried to set it to tbz2 according to ports.conf, but the resulting files, while ending in .tbz2, were not: /opt/local/var/db/dports/packages/darwin/i386/coreutils-6.7_1+with_default_names.i386.tbz2: POSIX tar archive So the code looks a little fragile in that it does regex matching on the names to determine which archiver and compressor to use. It also doesn't cover misspelled settings So a couple of things: 1) Should we decide on a standard tbz or tbz2? We should have the documentation match the code. 2) Have to code check for all valid types instead of trying regexps on them? Thanks, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
On Feb 28, 2007, at 6:29 PM, Blair Zajac wrote:
I was messing around with the portarchivetype option today and tried to set it to tbz2 according to ports.conf, but the resulting files, while ending in .tbz2, were not:
/opt/local/var/db/dports/packages/darwin/i386/coreutils -6.7_1+with_default_names.i386.tbz2: POSIX tar archive
This is because the switch statement taking care of setting up the archive type does not support a "bz2" ending for our tar based archives (as I'm sure you know by now if you read the proper source file, I'm just pasting here for discussion's sake ;-): in base/src/package1.0/portarchive.tcl: proc archive_command_setup {args} { (snip) switch -regex ${archive.type} { (snip) t(ar|bz|gz) { (snip) if {[regexp {z$} ${archive.type}]} { (snip) } } } } That '$' in "z$" kills our ability to handle "z2" as an extension ending, thus eliminating the possibility of dealing with either tbz or tbz2 named archives. "archivemode" having been questioned extensively before, I still say we fix this (in my opinion) rather important omission: personally, I would move from "tbz" to "tbz2" as I believe the latter is much more common; but I can understand how that would disrupt a maybe large portion if the user base already using "tbz", so instead I say we make room for both: - t(ar|bz|gz) { + t(ar|bz|bz2|gz) { - if {[regexp {z$} ${archive.type}]} { + if {[regexp {z2?$} ${archive.type}]} { - if {[regexp {bz$} ${archive.type}]} { + if {[regexp {bz2?$} ${archive.type}]} { (changes tested and working)
So the code looks a little fragile in that it does regex matching on the names to determine which archiver and compressor to use. It also doesn't cover misspelled settings
The "default" clause should cover them as errors in the ports.conf setting, prompting users to correct them, which seems sane to me.
So a couple of things:
1) Should we decide on a standard tbz or tbz2? We should have the documentation match the code.
My changes above should allow for both "tbz" and "tbz2", allowing the user to choose his/her favorite. If checked in, we would also patch documentation to list both options (cf. your r22465 commit). Opinions?
2) Have to code check for all valid types instead of trying regexps on them?
Maybe a tad too stringent....? Did you detect any errors (other than the one discussed here) in checking for supported archive types?
Thanks, Blair
Thanks for bringing this up! Regards,.. -jmpp PS: Truth be told, I think we should move to the by far much more standard "*.tar.gz" & "*.tar.bz2" naming convention, but I don't think many would care enough about "archivemode" to even dig into it to determine the effects such move would have. Do you? Hint, hint... ;-)
participants (2)
-
Blair Zajac
-
Juan Manuel Palacios