Syspkg

This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
Korona
Member
Member
Posts: 1000
Joined: Thu May 17, 2007 1:27 pm
Contact:

Re: Syspkg

Post by Korona »

bzt wrote:3. payload directories
If you can't use 2. in payloads, because you're importing someone else's repo, then you can specify overrides per package. For example "inc/" = "code/headers" or "inc/" = "include".
I guess that's what I meant. If I compile a random project using autotools or cmake and install it into a local sysroot (using make install), I will end up with a dir layout like this:

Code: Select all

lib/libhistory.so.7
lib/libhistory.so.7.0
lib/libreadline.so.7
lib/libreadline.so.7.0
share/doc/libreadline7/USAGE
share/doc/libreadline7/changelog.gz
share/doc/libreadline7/copyright
share/doc/libreadline7/examples/Inputrc
share/doc/libreadline7/inputrc.arrows
(taken from https://packages.debian.org/buster/amd6 ... 7/filelist, cleaned up a bit to remove the /usr prefix and Linux-specific paths.)
Now to convert that into a syspkg, I need to define these overrides. However, the overrides (e.g. shr = share) will be basically the same for all cmake/autotools/meson projects (= the majority of all projects that people will ever compile for their OSes; and they are the same because the paths are standardized by Linux' FHS). Thus, it would be nice to handle that in some generic way (instead of copy and pasting identical overrides into each json file).
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].
User avatar
bzt
Member
Member
Posts: 1584
Joined: Thu Oct 13, 2016 4:55 pm
Contact:

Re: Syspkg

Post by bzt »

Korona wrote:Thus, it would be nice to handle that in some generic way (instead of copy and pasting identical overrides into each json file).
Okay, I now see what you mean. You're right, there should be a compile time configuration too to set up defaults for overrides to avoid duplication on identical json config blocks. I'll look into that! Thank you for your feedback!

EDIT: okay, it's implemented! You can now specify default payload directories the same way as you specify file system directories, in config.h. If these *PDR payload directory defines aren't defined, they default to the 3 letter names, and you can still override them on per package basis as before.

Code: Select all

/* where the installed files are stored */
#define BINDIR "/usr/bin/"
#define INCDIR "/usr/include/%s/"
#define LIBDIR "/lib/%s/"
#define ETCDIR "/etc/%s/"
#define SRCDIR "/usr/src/%s/"
#define DOCDIR "/usr/share/man/"
#define SHRDIR "/usr/share/%s/"
#define VARDIR "/var/lib/%s/"

/* only used for the base package */
#define BASEDIR "/"

/* directories in payloads (optional, can also be specified on per package basis in metajson) */
#define BINPDR "bin"
#define INCPDR "include"
#define LIBPDR "lib"
#define ETCPDR "etc"
#define SRCPDR "src"
#define DOCPDR "docs"
#define SHRPDR "share"
#define VARPDR "var"
Cheers,
bzt
User avatar
bzt
Member
Member
Posts: 1584
Joined: Thu Oct 13, 2016 4:55 pm
Contact:

Re: Syspkg

Post by bzt »

@Korona: is this what you meant? Any more suggestions? This is a nice to have feature even if it wasn't the one you meant :-)

Cheers,
bzt
User avatar
bzt
Member
Member
Posts: 1584
Joined: Thu Oct 13, 2016 4:55 pm
Contact:

Re: Syspkg

Post by bzt »

New feature: the fields in the metajson with type URL (that is, "eula", "homepage", "bugtracker" and "screenshots") can now contain $LANG. This will be substituted by the two letter language code in which the package is going to be installed. That is the user locale's language code if the description is translated in that language, otherwise the first descriptions' language code.

Example

Code: Select all

{
    "id": "myproject",
    "description": [
        { "en", "My Project", "English description" }
        { "de", "Meine Projekt", "Deutche Beschreibung" },
        { "es", "Mi Proyecto", "Español descripción" }
    ],
    "version": "1.0.1",
    "release": "1.0-beta-rc",
    "url": "https://github.com/myuser/myproject/archive/$VERSION-$ARCH.zip",
    "category": "tools",
    "license": "MIT",
    "eula": "https://github.com/myuser/myproject/raw/master/LICENSE.$LANG.txt"
}
In this example if the user using syspkg has the locale "de" for example, then eula will be "https://github.com/myuser/myproject/raw/master/LICENSE.de.txt". On the other hand, if he's using "fr", then (since there's no French translation for the package) it's going to be "https://github.com/myuser/myproject/raw/master/LICENSE.en.txt" (because the first translation is "en").

Messing around with language code like this is necessary, because if there's no French translation for the package, then it is very likely that there's no French EULA either, therefore "LICENSE.fr.txt" would be a dead link, resulting in a HTTP 404. By only allowing values that are listed and defaulting to the first translation makes sure of it that eula URL will point to an existing license file.

FYI: EULAs are shown by package configurator hooks to the user before the package's payload gets downloaded. This is an entirely optional feature, and OS creator might decide to support it or not (by implementing the hook or not), and if so then the package maintainers can decide whether to actually use it for a particular package or not (by adding "eula" keys to the metajsons or not).

The provided syspkg demo command line tool's hook for example displays it like this (the contents of the license are downloaded from the "eula" URL):

Code: Select all

    Copyright (C) 2021 bzt (bztsrc@gitlab)

    Permission is hereby granted, free of charge, to any person
    obtaining a copy of this software and associated documentation
    files (the "Software"), to deal in the Software without
    restriction, including without limitation the rights to use, copy,
    modify, merge, publish, distribute, sublicense, and/or sell copies
    of the Software, and to permit persons to whom the Software is
    furnished to do so, subject to the following conditions:

    The above copyright notice and this permission notice shall be
    included in all copies or substantial portions of the Software.

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
    NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
    HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
    WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
    OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
    DEALINGS IN THE SOFTWARE.

Accept terms of use (Enter = yes, anything else or ^C = no)?
For a GUI, one possible way how to do it is similar to how MacOS .mpkg displays licenses, for example:
Image
However syspkg mandates that the link must point to a plain text file with the actual terms and a clear "Accept terms of use?" question must be asked with a clear "Yes" and "No" answer options (this is a lawyer's thing to comply with both USA and EU law, there must be a question and the answer options must be straightforward and clear. Using buttons like "Continue" above or "I comply" are not good; and I have absolutely no idea why Python is showing its history instead of its license).

Cheers,
bzt
Post Reply