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

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
 
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 ;)
 
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.
 
Zirias said:
I'm not sure I understand the intention of that, but it sounds kind of weird....
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top