Ryan Schmidt wrote:
>> $ file -b /opt/local/var/macports/distfiles/scapy/scapy-2.3.1.zip
>> POSIX shell script executable (binary data)
Those ought to be detected as executable scripts by libmagic, not as archives.
>
> Interesting, I did not know that kind of thing existed / was possible.
On Mar 31, 2016, at 11:35 AM, Rainer Müller wrote:
> Using magic bytes would even result in wrong results in some cases. For
> example for scapy, the distfile is intentionally a polyglot. It is both
> a valid shell script and a zip file:
>
> $ file -b
On 2016-03-31 03:16, Ryan Schmidt wrote:
> libmagic should be used to determine the compression format; filename
> extension should not be used.
Was there ever a case with a .tar.gz that was actually compressed with
bzip2 or something like this? The current approach of 'use_* yes' also
assumes
On Wednesday March 30 2016 20:16:37 Ryan Schmidt wrote:
>libmagic should be used to determine the compression format; filename
>extension should not be used.
I'd agree with that - if introducing an additional dependency isn't an issue.
I guess that the set of compression formats to recognise is
On Mar 30, 2016, at 3:06 PM, Mojca Miklavec wrote:
> On 30 March 2016 at 19:25, René J. V. wrote:
>>
>>> It is fairly obvious how to extract these files. There is usually no
>>> need to specify how these files should be extracted, since most
>>> compression methods can be deduced from the
On 30 March 2016 at 19:25, René J. V. wrote:
>
>> It is fairly obvious how to extract these files. There is usually no
>> need to specify how these files should be extracted, since most
>> compression methods can be deduced from the filename.
>>
>> The command 'use_* yes' would then only set the
Rainer Müller wrote:
> In case of multiple distfiles you will always specify the full name
> anyway. This would be that for an option such as this example:
>
> distfilesfoo.tar.gz \
> bar.tar.xz
Yes, *fetching* isn't the problem here.
> It is fairly obvious how to extract
On 2016-03-26 22:20, René J.V. Bertin wrote:
> On Saturday March 26 2016 02:27:49 Ryan Schmidt wrote:
>
>> Don't think of them as commands. Think of them as radio buttons.
>
> Typically that would mean that if you "push" another one of them, the
> previous choice is undone.
> That doesn't seem
On Saturday March 26 2016 02:27:49 Ryan Schmidt wrote:
> Don't think of them as commands. Think of them as radio buttons.
Typically that would mean that if you "push" another one of them, the previous
choice is undone.
That doesn't seem to be the case here.
> Hmm, that could be considered a
On Mar 25, 2016, at 4:30 PM, René J.V. Bertin wrote:
> On Friday March 25 2016 20:59:47 Ian Rees wrote:
>
> Hi Ian,
>
>
>> for ccs, and a .tgz for spooles. As far as I could figure out, the fetch
>> step can handle multiple files, but the extract step can not.-Ian-
>
> That's what I
On Friday March 25 2016 20:59:47 Ian Rees wrote:
Hi Ian,
> for ccs, and a .tgz for spooles. As far as I could figure out, the fetch
> step can handle multiple files, but the extract step can not.-Ian-
That's what I figured would happen indeed.
A related observation: you can only use one
Hi René,
I had a similar situation recently making the Portfile for ccx:
https://trac.macports.org/ticket/50810 . There is one .tar.bz2 download
for ccs, and a .tgz for spooles. As far as I could figure out, the fetch
step can handle multiple files, but the extract step can not.-Ian-
12 matches
Mail list logo
