I'm currently working on packaging github.com/writeas/writefreely, a platform for building writing spaces. Some of its dependencies are currently not packaged for Fedora, so I'm seeking some advice on the granularity to which I should be packaging each dependency.
github.com/writeas/writefreely depends on github.com/writeas/web-core. This is a library that is used by the project developers (write.as) for all their shared code. It is likely that this will be used as a dependency for future packages (for example, when their photo sharing service, snap.as, gets released), but unlikely that it will ever be used by anyone other than these developers.
Therefore, should github.com/writeas/web-core be its own package, should I bundle it in with writefreely, should it be a subpackage of writefreely, or indeed something else?
Additionally, web-core has its own dependencies of the same kind. Where possible, I have submitted PRs[1,2,3] to their repo to reduce unnecessary dependencies, but web-core still depends upon github.com/writeas/impart and github.com/writeas/openssl-go. These libraries are both unlikely to be used anywhere else; should these be bundled too?
If the correct course of action is to bundle the dependencies (in a nested way), I would really appreciate somebody experienced at packaging Go packages to give some guidance on how to do this sensibly with the Go SPEC file macro system. This is especially since the current documentation seems pretty light on the topic of dealing with SPEC files with multiple sources.
Also, this is my first time joining a mailing list to actually get involved with the Fedora project, so do let me know if this sort of question actually belongs elsewhere.
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-09-17 16:00 UTC in #fedora-meeting-1 on
Local time information (via. uitime):
================= Day: Thursday ==================
2020-09-17 09:00 PDT US/Pacific
2020-09-17 12:00 EDT --> US/Eastern <--
2020-09-17 16:00 UTC UTC
2020-09-17 17:00 BST Europe/London
2020-09-17 18:00 CEST Europe/Berlin
2020-09-17 18:00 CEST Europe/Paris
2020-09-17 21:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2020-09-18 00:00 HKT Asia/Hong_Kong
2020-09-18 00:00 +08 Asia/Singapore
2020-09-18 01:00 JST Asia/Tokyo
2020-09-18 02:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
= Followup Issues =
#topic #907 Which %__foo macros for executables are acceptable?
= Followup Pull Requests =
#topic #pr-814 Add SELinux Independent Policy Guidelines.
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
If you would like to add something to this agenda, you can:
* Reply to this e-mail
* File a new ticket at: https://pagure.io/packaging-committee
* E-mail me directly
* Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
Background - https://bugzilla.redhat.com/show_bug.cgi?id=1878306
conda can provide an /etc/fish/conf.d/conda.fish file for fish users.
As usual, we do not want to add a dependency on fish for conda. For now
I think I'll just have conda own /etc/fish and /etc/fish/conf.d, but
what do we want to do going forward? Add it to filesystem? Create a
Surprisingly, I can't find any other packages that ship
/etc/fish/conf.d/* files, so maybe this just isn't an issue worth taking
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
Meeting started by geppetto at 16:00:29 UTC. The full logs are available
* Roll Call (geppetto, 16:00:29)
* Schedule (geppetto, 16:05:11)
* LINK: https://pagure.io/packaging-committee/issue/907 also looks
like it might be done? (geppetto, 16:15:39)
* Open Floor (geppetto, 16:22:26)
* ACTION: decathorpe Look through all the non-meeting tickets to see
if any are stuck and need to be discussed. (geppetto, 16:24:33)
Meeting ended at 16:30:08 UTC.
* decathorpe Look through all the non-meeting tickets to see if any are
stuck and need to be discussed.
Action Items, by person
* decathorpe Look through all the non-meeting tickets to see if any
are stuck and need to be discussed.
People Present (lines said)
* geppetto (34)
* zodbot (16)
* mhroncok (12)
* tibbs (11)
* decathorpe (5)
* King_InuYasha (3)
* limburgher (3)
* carlwgeorge (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
an interesting problem has been reported in Bugzilla 3 years ago:
tl;dr There are generated files in /usr/share/mime without owning packages.
When update-mime-database database is run (by RPM trigger), files are generated
in /usr/share/mime, such as:
│ ├── andrew-inset.xml
│ ├── annodex.xml
│ ├── ...
│ └── zstd.xml
│ ├── audio-cdda.xml
│ ├── ....
│ └── win32-software.xml
The files are generated based on content form multiple packages. I.e.
shared-mime-info cannot list all the files as %ghosts because the list of files
As a specific example, on my system, I have:
The file in packages/ is shipped and owned by the openscad package.
The file in application/ is generated by update-mime-database.
So I guess the questions are:
Should shared-mime-info %ghost all files created by update-mime-database when
only shared-mime-info is installed? (That seems to be easy enough).
Should individual packages shipping mime files %ghost the files generated from
them? E.g. should openscad %ghost /usr/share/mime/application/x-openscad.xml?
Is there a better (possibly automated) way of doing it? Or is it not worth it
and we simply say that the files are OK not being owned?
Please have a look on this issue and give your +1 or -1:
> Golang package review exception to update a lot of packages
I have finish all the Package Reviews and I'm ready for some dist-git action.
Thanks for your time,