Will `pacote` be an exact reimplementation of Sun's package management system?

[xplshn]

Hi, I'm interested in helping out with pacote. Does it have to be an exact match of Sun's package management suite/system? I'm planning to write one anyways for my toy/very-w.i.p distro (Andes). And I'm also gonna be rewriting bigdl (probably).

I was thinking, that, if its all crafted in Go, we could use https://github.com/u-root/gobusybox to save space, and have the package manager be a single binary, that is then symlinked to installf, pkgadd, and so on.

Anyways, I really really want to contribute, because I'm excited for this project. I've been pursuing the Unix feel but the comfort of Linux for way too long, and never have I seen a serious project doing exactly that. Alpine is great, but they're not striving for that, and the docs and community are not really approachable. I think what you're doing is amazing, and want to help out any way possible to get to a usable version as soon as possible.

[takusuman]

Hi, I'm interested in helping out with pacote.

Pardon for the delay, I'm somewhat busy on the main part of Copacabana.

Does it have to be an exact match of Sun's package management suite/system?

I mean, almost. We want to have something that follows what is specified on Sun's specification, but without rendezvousing with errors made in the past and also implementing new features that would be nice to have --- such, for example, outputting JSON in pkginfo(1). I think these can be discussed along the way, by the way. Another point is to document it better since the Sun standard, even though it is complete, it is not as "humanly documented" as I would like it to be. I think our documentation could also show some internal code examples since, unlike Sun's implementation back in the 1990s/2000s, it is fully open source.

I was thinking, that, if its all crafted in Go, we could use https://github.com/u-root/gobusybox to save space, and have the package manager be a single binary, that is then symlinked to installf, pkgadd, and so on.

Of course we can add a target for this in the makefile, if it's simple to implement. I think Copacabana can be "thicker" since I aim to have a "desktop UNIX-esque system", so compacting the binaries as one and having symlinks may not be needed --- but since, like Heirloom NG, pacote is meant to be portable to other environments, we can do that.

Anyways, I really really want to contribute, because I'm excited for this project.

I appreciate that, really. 🥲 I think I will be reworking some parts of this tomorrow, I have just refactored Copacabana's build system and now it seems simpler to develop than before. If you have any other questions, you can open another issue (or respond here) and we can set more ideas from there.

[xplshn]

I think our documentation could also show some internal code examples since, unlike Sun's implementation back in the 1990s/2000s, it is fully open source.

This is an excellent decision. I think we could take some inspiration from the manpages of Unix 10th edition, Plan9's/Inferno's and OpenBSD's.

OpenBSD's always have a section called "STANDARDS", which specifies to which standards the implementation/program adheres and where it deviates from them.

Plan9's always have a "SOURCE" section, indicating where one can see the source code of the program, it usually lists where the program sits in the /sys/src tree and then where the binary of the program is supposed to be.

Inferno manpages more often than not contain a section called "FILES" where they list what files the program accesses and for which purposes, that includes device nodes, file types (since its plan9 and everything is a file or a file system [a file too]), it also indicates if the file is volatile or not. Just really insightful stuff.

Unix's 10th edition manual has a concise "BUGS" section, sometime also included in Plan9's manpages, they usually cover "BUGS" that won't be fixed due to them being very, very edge-cases, and when fixing those bugs probably adds new ones due to adding a lot more complexity to the program. I think that's also great to have in a manpage, sincerity from the devs.

[takusuman]

I think these would relate more to manual pages, I'm talking about developer documentation, or the so-called "tabulas".

[xplshn]

Of course we can add a target for this in the makefile, if it's simple to implement. I think Copacabana can be "thicker" since I aim to have a "desktop UNIX-esque system", so compacting the binaries as one and having symlinks may not be needed --- but since, like Heirloom NG, pacote is meant to be portable to other environments, we can do that.

Yes, however, its just that having it is nice, even if your system can be thicker, why waste +0.2megs for each ELF file header+Go metadata that goes along with them? Access times are faster if you aren't reading different files all the time, and your PC can cache things nicely this way.

[xplshn]

I think these would relate more to manual pages, I'm talking about developer documentation, or the so-called "tabulas".

Ahh, yes... Forgot the issue is in the pacote repo... lol

[takusuman]

Yes, however, its just that having it is nice, even if your system can be thicker, why waste +0.2megs for each ELF file header+Go metadata that goes along with them? Access times are faster if you aren't reading different files all the time, and your PC can cache things nicely this way.

Didn't knew that, neat. Yes, we can do that.

[takusuman]

I think these would relate more to manual pages, I'm talking about developer documentation, or the so-called "tabulas".

Ahh, yes... Forgot the issue is in the pacote repo... lol

I think the "tabulas" of each project can be on the respective repositories, the Silicon-Tabula repository will only collect the subrepos and have a recipe to build them as a site.

[takusuman]

I think these would relate more to manual pages, I'm talking about developer documentation, or the so-called "tabulas".

Ahh, yes... Forgot the issue is in the pacote repo... lol

I think the "tabulas" of each project can be on the respective repositories, the Silicon-Tabula repository will only collect the subrepos and have a recipe to build them as a site.

In other words, no problem to talk about documentation here.

[xplshn]

I think these would relate more to manual pages, I'm talking about developer documentation, or the so-called "tabulas".

Ahh, yes... Forgot the issue is in the pacote repo... lol

I think the "tabulas" of each project can be on the respective repositories, the Silicon-Tabula repository will only collect the subrepos and have a recipe to build them as a site.

Unrelated, but I think the repo names should be descriptive of what they contain when you're working in an "organization" and not signed in like a user. I think that makes it easier for people to modify the distro, re-compile it, etc. Tabula is not very descriptive as a repo name, but once the person's read the README.md I think it is not a problem. I like the name, but I think the repo's name should change

[takusuman]

Tabula is not very descriptive as a repo name, but once the person's read the README.md I think it is not a problem. I like the name, but I think the repo's name should change

I thought the description should address this. What do you suggest? Rapidly thinking, I propose something on the lines of "tabula-docs".

[xplshn]

Tabula is not very descriptive as a repo name, but once the person's read the README.md I think it is not a problem. I like the name, but I think the repo's name should change

I thought the description should address this. What do you suggest? Rapidly thinking, I propose something on the lines of "tabula-docs".

I think the WWW repos could be divided into: www (main pages, with links to the Silicon-Tabula) www-docs (the Silicon-Tabula repo) www-extend (a repo for documenting external programs/behavior when used in Copacabana, e.g, if we've applied patches or some programs are buggy when compiled with LLVM/Clang/ZigC)

[xplshn]

That also means that the WWW repo could have the WWW-docs and WWW-extend repos as submodules, instead of manually having to go through each, compile/export to HTML and then reunite it all back again.

[takusuman]

That's a great plan --- principally for extend, I haven't thought about that before, like a bug database ---, can I apply later? Currently there's pretty much nothing done other than stubs for documentation, not even the Hugo site and theme (traité) are configured yet. Since I work on Copacabana almost alone for the matter of building the system, I'm a little busy for reconfiguring repositories right now. I'll be writing about cross-compilation, though.

[xplshn]

That's a great plan --- principally for extend, I haven't thought about that before, like a bug database ---, can I apply later? Currently there's pretty much nothing done other than stubs for documentation, not even the Hugo site and theme (traité) are configured yet. Since I work on Copacabana almost alone for the matter of building the system, I'm a little busy for reconfiguring repositories right now. I'll be writing about cross-compilation, though.

That's a great plan --- principally for extend, I haven't thought about that before, like a bug database

Yes, exactly, I think it would help with development, you won't have people opening issues all the time about programs that don't work because with the "bug database" we could give clear instructions on what to patch and where, or why the issue happens and how to workaround it, etc. Think this would make it easier both for you and for anyone trying out the distro (once we get to an alpha release state)

Also, what do you mean with: "can I apply later?", I didn't get that...

[takusuman]

Back here again.

[takusuman]

https://github.com/Projeto-Pindorama/pacote/blob/485683cc33c30b340bf71c778c84dc8b69753390/cmd/pkgproto/main.go#L66-L67

If I got it right from the documentation, assigning a new path to a filename and/or a path on the package means that pkgadd will pretty much copy these to this new path?

Defining Additional Objects to Be Created at Install Time You can use the prototype file to define objects that are not actually delivered on the installation medium. During installation, using the pkgadd command, these objects are created with the required file types, if they do not already exist at the time of installation. To specify that an object be created on the target system, add an entry for it in the prototype file with the appropriate file type. For example, if you want a directory created on the target system, but do not want to deliver it on the installation medium, make the following entry for the directory in the prototype file:

d none /directory 0644 root other

If you want to create an empty file on the target system, an entry for the file in the prototype file might look like:

f none filename=/dev/null 0644 bin bin

The only objects that must be delivered on the installation medium are regular files and edit scripts (file types e, v, f) and the directories required to contain them. Any additional objects are created without reference to the delivered objects, directories, named pipes, devices, hard links, and symbolic links.

Source: the specification from February 2000

Eh... Maybe pkgproto needs at least a refactor to handle some cases. I would recommend a reading from the page 20 of the standard until the page 34.

[xplshn]

Yes, assigning a new path to a filename or path in the package means that pkgadd will create these objects at the new path during installation. But it doesn't mean that they will be copied, the prototype file, as it says, can specify files that aren't shipped within the package itself, for example, if your program creates some files in /usr/share, they have to be specified in the prototype for them to be removed, that's why the prototype file specifies files which may not be contained within the package file.

[takusuman]

Yes, assigning a new path to a filename or path in the package means that pkgadd will create these objects at the new path during installation. But it doesn't mean that they will be copied

Thanks for the explanation. I thought it copied because of the example given, which proposes that an empty file can be created with filename=/dev/null.

[takusuman]

We can take some of Sun's code as reference and have a notion of how pkgproto is meant to operate, besides the documentation: https://github.com/Arquivotheca/Solaris-8/blob/2.8/osnet_volume/usr/src/cmd/oampkg/pkgproto/main.c

The only problem is that this code "smells like naphthalene", like we use to say here in Brazil, and is far less modular than pacote's code, but I think we can confirm some ideas with it.

[xplshn]

We can take some of Sun's code as reference and have a notion of how pkgproto is meant to operate, besides the documentation: https://github.com/Arquivotheca/Solaris-8/blob/2.8/osnet_volume/usr/src/cmd/oampkg/pkgproto/main.c

The only problem is that this code "smells like naphthalene", like we use to say here in Brazil, and is far less modular than pacote's code, but I think we can confirm some ideas with it.

I think this may be a better reference, there's also the manpage there. https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/svr4pkg/pkgproto/main.c

[takusuman]

I mean, funnily enough, there's an undocumented option on Solaris 8 implementation.