Page Operations
Browse Spacekeyword on this page is the future in the title. This is a work in progress.
Focus
Our stated focus is to do the best possible job of allowing Foresight Linux to be the early, and default, provider of upstream bits, in a sane, reliable and consistent way.
goals
the end-goal of any (product) development model is to get accountability, predictability, scalability in order to get stability and quality on the goods deliverable. Everything else is subsidiary to this.
... from a development standpoint
- to make the overall development process manageable, predictable and accountable.
- to accurately reflect, at any given time, the 'state of art', for any given package.
- to ease, as possible, developer adoption, by taking as much as possible, advantage of established best practices, and de-facto standards.
 | conary is 'just' a packaging technology, the best one, but still just a packaging technology. And, a packaging technology, per definition, as good or evolved as it may be, will never be a substitute to understand what is being packaged in concrete, and it's role in a higher level stack. Also, no one, on sane grounds, should expect anyone to be fluent on all packages, all stacks, all levels. More, the core basis of the whole open source development model, what really makes it scale, is openness and collaboration. We do not have the resources, the people, the money, nor we should have the ego, to try, even pretend to, reinvent the wheel. If something is well done/maintained elsewhere, and it works and suits our needs, and we can legally leverage it, we should just use it, and move ahead. We should just invest our time, which is our most precious resource, in places where we can add value and make a difference, for the better. Being just different will not bring us any good, being better will. |
Development guidelines
on packaging
on packages for which we don't have specific know-how, or where there are no perceived value on maintaining/tracking them, on our own, we will - on our recipes - just follow RH's packaging, patches and version bumps, as they will be our baseline.
Caveats are...- We will ignore everything, from patches, to build options, to whatever, selinux related.
- We will ignore everything gcj related. We'll rely solely on icedtea/openJDK instead.
- RH goes to great lengths to ensure that, on 64 bit arches, for any given package, their devel 32 bit counterpart devel stuff installs side by side. For the sake of (recipe) simplicity, we 'll ignore everything related to this¸as it doesn't add significant value
- we will ignore everything not relevant to x86{,_64} platforms.
- on package and subPackage naming, we will byDefault follow RH's naming/pkgSpecing. Exceptions will be considered in a case by case basis.
- on the buildRequires / Requires of any given package, ours should be a superset of RH's ones.
- we should make sure that on :doc the stuff RH's rpm's are either equal or a subset of ours.
- all packages should have proper metadata set. this is mandatory. (see bellow, for the metadata guidelines)
on file layout
We will follow exactly RHs/Fedora file layout conventions, for compatibility and convenience. Exception, will be hooks, to preserve existing behavior, or to assure migration paths. If, and when, we deviate, it should be documented properly why.
on metadata (FIXME format to be set / detailed ASAP)
metadata is to be stored in a INFO file. that file is to be read/parsed at build's end, either with cvc cook or rmake.
metadata contents have several distinct uses.- to properly populate trove {long,short}Descriptions.
- to properly set Licenses, etc.
- to allow for scripted ways to automate/monitor maintenance tasks.
on package maintenance
Packaging is not the hardest part. Maintaining a package is. A logical corollary is that we should only have to worry with the stuff we feel comfortable with; for all else we follow upstream decisions. When not, we should document the why.
| Keep in mind It is better not to provide a given package, than to ship a broken one. |
x86 and x86_64 feature parity
All packages must build, and be tested in x86 and x86_64, before being committed. If they are arch specific, then they should be tagged accordingly. (see the metadata guidelines belloe)
Proper package metadata is now mandatory
All and every package should have its metadata properly set.
Repository's new label structure
—
bootstrap:toolchain
Stuff to be {cross-,}bootstraped. basically toolchain + conary.
flavor is 'bootstrap'
bootstrap:userland
Stuff that is a buildReq of the stuff in bootstrap:toolchain.
to be rebuilt in '!bootstrap' flavor form against it.
bootstrap:toolchain-rebuild
:sources are the same as in bootstrap:toolchain, except for the group.
Gets rebuilt in '!bootstrap' flavor resolving against bootstrap:userland
bootstrap:userland-rebuild
:sources same as in bootstrap:userland
Gets rebuilt in '!bootstrap' resolving against bootstrap:toolchain-rebuild—
devel:autoloaded
Our custom autoloaded superclasses.
Autoloaded superclasses need to be cooked manually thru cvc cook.
We put them in a separate label in order for rmake --recurse of devel:tip top level group to behave.
devel:id
User and group troves.
In a separate label, to avoid unnecessary rebuilds anytime we --recurse devel:tip
devel:classes
Superclasses only.
Given that we intend to rebuild everything in devel:qa, we may want to have also a devel:classes-qa—
devel:tip
Contents of bootstrap:userland-rebuild and bootstrap:toolchain-rebuild, minus their groups, plus everything and the kitchen sink.
ALL :source contents must be buildable, ence the classes elsewhere except for low level stuff, relating to toolchain, all action happens here.
devel:qa
Name says it all. stuff (not coming initially from bootstrap:userland-rebuild and bootstrap:toolchain-rebuild) lands from :tip always as :source to be rebuilt natively.
devel:staging
Pre-releases. promotes from devel:qa, and local group builds
workflow exception are security fixes, who can get straight to here.
TBF
