# Are RPM sources acceptible for use as source packages to become port trees?



## HD Scania (Mar 18, 2022)

I’m about to make my own unofficial port trees uploaded on a Git project, and FreeBSD has a binary pkg also named RPM, but could it fit for use of port trees?


			Index of /trinity/rpm/pclinuxos/trinity-r14/SRPMS/


----------



## T-Daemon (Mar 18, 2022)

Is there a particular reason to use source files archived in RPM packages?

There are Trinity release R14.0.11 source .tar.xz archive files available (as single or combined downloads).


----------



## HD Scania (Mar 24, 2022)

Tarballs is also an option, and one of the final port differences is, my `Trinity_RPM` edition will require an install of RPM, whose base OS project is PCLinuxOS
And your `Trinity_tarballs` edition requires nothing not native, so both editons will be found in my personal ports of a FreeBSD LiveDVD project
I.e. `Trinity_RPM` and `Trinity_tarballs` are supposed to be the mutual mirrors, which both trees are hosted on the same official Trinity TDE project
Also, i have Liri shell coming from Linux to be put into my FreeBSD port trees for that same LiveDVD project, and their official Git trees on GitHub are used
Having done everything above for uploads exclusively uses Git serrvices
PS: Liri shell is written firstly for Fedora also packaging by RPM, but every 3 years RPM sources die 4 times, too unstable for static porting, so only Git trees are used for porting Liri shell

My porting expects online to online direct porting, only when those ports are being installed by an user, or whose source Git trees or RPM sources or tarballs will never be downloaded
When whose deps also come from those Git trees or source archives themselves, active installs and deps will also be downloaded together after an install instruction by an user starts running


----------



## kpedersen (Mar 24, 2022)

You might not be able to fall back on the default infrastructure provided by the ports build system and instead you may have to write some custom extract functions using `rpm2cpio`. However unless you can find a better or more standard archive it isn't forbidden. For example some ports extract files out of Windows .exe's via unpackers which is hardly standard


----------



## zirias@ (Mar 24, 2022)

I'm not sure I understand the intention of that, but it sounds kind of weird....

Background: Many Linux package building systems use a "package by package" approach, meaning you maintain build instructions, local patches, and whatever is needed for each and every package. A source-RPM typically contains such a thing (and also includes the original source).

Ports are an entirely different approach, where _all_ build instructions, patches, etc for _all_ packages are maintained in a single source tree, but original source is not included there. Vanilla upstream source is obtained as part of the build, typically distributed in tarballs.

So, using a source-RPM for a port kind of sounds like an oxymoron.


----------



## HD Scania (Mar 24, 2022)

Trinity also maintains their own Git server, https://mirror.git.trinitydesktop.org/gitea/explore/repos
AUR has two channels for a same package, Git uses complete sources downloaded from Git trees, non-Git uses tarballs which is of only vanilla sources
But why porting sth onto FreeBSD only uses tarballs (vanilla sources) but doesn’t use Git trees (complete sources)?


----------



## zirias@ (Mar 24, 2022)

Uh. What?


----------



## kpedersen (Mar 24, 2022)

Zirias said:


> I'm not sure I understand the intention of that, but it sounds kind of weird....


The only case I can think of was an old Quake III level editor source code being hosted as an .srpm rather than a classic tarball. It was weird but I also know that game developers specifically do weird things as they often don't quite know about standard software engineering practices.


----------

