> > It is a clear thematic division to me.  Though it's a bit large,
> > maybe 'applications' could be divided futher in more specific
> themes
> > (‘office’ apps, games, terminal utilities, ...).
> Yeah, that division makes more sense, but note that none of the
> categories you cited call specifically for SSL_CERT_DIR/FILE.  It
> really is curl, which you might categorize as "terminal utility", but
> more accurately fits into "web" along with nss-certs, for example.

I don't have 'curl' or 'wget' installed.

'minetest' falls under games and can be used offline, yet it requires
SSL_CERT_DIR/FILE for contacting its ‘mod’ server ContentDB.

In the past, I've had a 'calibre' package installed, which in some
usage modes contacts the network and needs TLS certificates (I don't
know if it respect SSL_CERT_DIR/SSL_CERT_FILE) -- I guess I would
classify it as ‘office‘, not ‘web’

'emacs' can be used to browse the ‘web’ (and hence might respect
SSL_CERT_DIR/SSL_CERT_FILE, not sure), yet it would be classified as
maybe ‘office’ but not ‘web’.

I guess ‘git’ could be classified as ‘web’, but it seems more something
for ‘terminal utilities’ or such to me, and it uses certificates for
repositories over https://.

‘gpg’ looks like something for ‘terminal utilities’ to me, yet it can
contact keyservers (though I'm not sure it can do so over HTTPS), which
might need certificates (I don't know if it respects
SSL_CERT_DIR/SSL_CERT_FILE).

'vlc' can stream videos from over the Internet (over HTTP or HTTPS), so
it might need certificates (I don't know if it respects
SSL_CERT_DIR/SSL_CERT_FILE), but it doesn't seem like ‘web’ to me.

AFAICT, the only for reason SSL_CERT_DIR/SSL_CERT_FILE would be set on
my system, is the ‘youtube-dl’ package (that is, once the search path
is added to the package), and the ‘openssl’ package, which AFAICT was
only installed to work around ‘SSL_CERT_DIR/SSL_CERT_FILE is not set
because many packages forget SSL_CERT_DIR/SSL_CERT_FILE in the native-
search-paths'.

Liliana Marie Prikler schreef op vr 06-05-2022 om 23:32 [+0200]:
> > > But what's more both nss-certs, glibc-locales and other packages
> > > that on their own provide everything you need in a search path
> > > can
> > > already be handled easily with existing mechanisms of Guix Home.
> > 
> > I haven't found any such mechanism -- I haven't found any hits for
> > 'GUIX_LOCPATH' or SSL_CERT_DIR/FILE'.  At most I've found
> > 'environment-variables->setup-environment-script', but as user I
> > just
> > want to add packages to a profile and have it work without having
> > to
> > manually fiddle with environemnt variables.
> I'm pretty sure Guix Home allows you to write your bashrc with gexps,
> no?  So you could put (string-append "export SSL_CERT_DIR=" #$nss-
> certs "/etc/ssl/certs") in there IIRC.

That's the kind of manual fiddling I was referring to (I don't want to
have to known any Bash more complicated that just starting some
binary), which I'd like Guix Home to automatically do for me instead. 
Why can't Guix (Home) do this for me?  Also, ~/.bashrc is Bash
specific, did you mean ~/.profile or .../etc/profile instead?

> > [search paths things]
> Perhaps, but this requires more than simply a declarative way of
> managing profiles, which is the main point here.  It would require
> search-paths as first class citizens of profiles in addition to that,
> which I already mentioned a few times in between.

As such, I consider addressing the search paths limitation a
requirement for the new ‘separated profiles with Guix Home’, though as
I understand it, you do not consider it to be a blocker?

Greetings,
Maxime.