Re: [9front] pkg/unpkg strangeness

Re: [9front] pkg/unpkg strangeness

[sl]

> According to tar(1):
> 
> File path names are limited to 100 characters (256 when
>           using ustar format).
> 
> Every file that has a path bigger than that leads to pkg/unpkg trying
> to unpack the file into /.

I don't see where tar(1) is ever getting called.

Note: I do not really understand unpkg.c.

sl

Re: [9front] pkg/unpkg strangeness

[Iruatã Souza]

Unpkg tries to be a tar xv printing "A path" to stdout and "path
checksum" to stderr.
It only knows about the tar format (100 chars limit in path), but
tar(1) compresses using ustar (256 chars limit in path) if needed.

imo, unpkg should be rewritten in rc.

On Mon, May 11, 2015 at 6:33 PM,  <sl@9front.org> wrote:
>> According to tar(1):
>>
>> File path names are limited to 100 characters (256 when
>>           using ustar format).
>>
>> Every file that has a path bigger than that leads to pkg/unpkg trying
>> to unpack the file into /.
>
> I don't see where tar(1) is ever getting called.
>
> Note: I do not really understand unpkg.c.
>
> sl

Re: [9front] pkg/unpkg strangeness

[Aram Hăvărneanu]

On Mon, May 11, 2015 at 11:44 PM, Iruatã Souza <iru.muzgo@gmail.com> wrote:
> imo, unpkg should be rewritten in rc.

Or deleted.

-- 
Aram Hăvărneanu

Re: [9front] pkg/unpkg strangeness

[Iruatã Souza]

even better

On Mon, May 11, 2015 at 6:46 PM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
> On Mon, May 11, 2015 at 11:44 PM, Iruatã Souza <iru.muzgo@gmail.com> wrote:
>> imo, unpkg should be rewritten in rc.
>
> Or deleted.
>
> --
> Aram Hăvărneanu

Re: [9front] pkg/unpkg strangeness

[sl]

> imo, unpkg should be rewritten in rc.

For what it's worth:

I was never happy with pkg(1) as the result of our early discussions
about creating a ports system.

My original suggestion was something more like what OpenBSD does: We
would maintain (only) mkfiles that include targets for download, hash,
patch, install, uninstall, etc., and not bother with the rest.  This
got lost in the discussion with other participants.  We ended up with
an initial pkg(1) system that distributed binaries and at first didn't
even include the source files used to build the package.

There are other quirks.  For example, pkg(1)'s rc scripts get
installed into /$objtype/pkg.

The original author vanished and I've ended up maintaining the package
repository as well as doing a generally poor job adding small
features, like including the source files in the packages.  It's not
entirely clear to me why unkpg is a c program in the first place.

Recently, there has been talk again on IRC about creating yet another
ports system.  I took this opportunity to once again advocate for a
simple set of conventions for using mkfiles.  Someone else suggested
what I thought was a good idea: Install each package (source and
binaries) into its own root under some arbitrary package directory and
then bind the needed files into place.  A mkfile target could print
the needed bind commands.  This would completely eliminate the need to
invent any new mechanism to track installed files.  To see what's
installed, use ls.  To uninstall, use rm.

That said, I'm no longer in favor of any kind of ports system at all.
This stuff always boils down to a lot of arguing and coordination and
bookkeeping without much real benefit.

sl

Re: [9front] pkg/unpkg strangeness

[Iruatã Souza]

According to tar(1):

File path names are limited to 100 characters (256 when
          using ustar format).

Every file that has a path bigger than that leads to pkg/unpkg trying
to unpack the file into /.


On Mon, May 11, 2015 at 5:28 PM,  <sl@9front.org> wrote:
> Someone mailed me pointing out that the old equis package aborts
> during installation. I was able to reproduce. On a 386/9pcf system:
>
>         ; pkg/install equis-2012.01.11
>
>         -- snip --
>
>         A ps2pdf_spooltodir.sh
>         pkg/unpkg: 'ps2pdf_spooltodir.sh' mounted directory forbids creation
>
>
> I manually unpacked equis-2012.01.11.tbz and found this:
>
>         ; ls
>         386
>         sys
>         ; du -a * | sed 's/^.*  //g' | grep ps2pdf_spooltodir.sh
>         sys/src/pkg/equis-2012.01.11/cmd/X/hw/xprint/config/C/print/models/PS2PDFspooldir-GS/ps2pdf_spooltodir.sh
>
> Makes no sense. The tarball is supposed to just unpack over /. As you
> can see, nothing should get created directly in / (/386 and /sys already
> exist on every system). pkg/unpkg must be doing something strange.
>
> I do think we saw this before and I forgot to investigate.
>
> Why is this happening?
>
> sl