[arch-dev-public] Repo Distinctions

[Essien Ita Essien]

Jason Chu wrote:
>>>> Of course, if the argument is that devs should maintain packages in
>>>> [community] because the distinction between devs and TUs isn't
>>>> important, another solution would be to flatten things and have [core],
>>>> [mantle] and [extra] and let TUs and devs maintain packages in [extra].
>>> Another thing would be to have community integrated in extra.
>> This has always been my preferred solution. Heresy you may say, but just 
>> sit back and think of it. Some developers prefer packaging work and 
>> others prefer tool-chain kinda work. If we could clone those that prefer 
>> packaging work, would it increase the amount of high quality and 
>> maintained packages in [extra] ? (can i get a big "oh... yeah!") (mooo!)
> 
> +1 I agree.
> 
>> joking aside though. I think we just need to actually DOCUMENT a strict 
>> packaging standard (this exists already. no?), and then open up the
>> flood gates to new upcoming would be _packagers_. No distinctions... 
>> just one high quality highly udated repository.
> 
> Define strict packaging standard.  I'm just trying to figure out how
> difficult this would be.  I've tried writing packaging tutorials before...
> I got bored...

By strict... i mean that it can be _codified_ by a program like namcap. 
Ofcourse there would have to be levels of fuzziness, but we can only 
define the allowable level of fuzziness as we actually try the approach.

What I propose is agreeing to something like say, before _any_ package 
can be accepted into an official repo, it should score like:
	70% prebuild on namcap (no Errors, only 30% of warnings allowed)
	90% build on makepkg (absolutely no Errors! wouldn't even build.. heh!)
	70% postbuild on namcap (No errors. only 30% of warnings)

The job the Cloning commitee (ahem!).. i mean Packaging Standards Group, 
will be to say what these metrics in namcap and makepkg should be and 
document that publicly. (An added benefit is that automated tools can be 
used to do this totally without human intervention - more movie watching 
time to devs!)

This would effectively refactor the as yet unwritten *strict* Packaging 
spec document a Three liner:
	All submitted package should pass X% namcap prebuild verification (i.e. 
running namcap on raw PKGBUILD file)
	All summitted packages should build via makepkg with above X% ratting.
	All submitted packages should pass X% namcap postbuild verification 
(i.e. running namcap on the resulting pkg.tar.gz file.

Ofcourse there would be the neccessary parts on how to get your verified 
package into the official repo. Let me not digress with this now though.

I also get bored writing tutorials and docs, but spec'ing in code... now 
there's a thought! What do you think?
> 
>>> Separation of devs and TUs is not the same as separation of their
>>> packages into different repos just by factor of package ownership.
>> I would say... _all_ packagers can maintain in [extra] but only 
>> Packagers who are also Developers can maintain in [core]. After that... 
>> maintain your own private repo or something. You say what about AUR? 
>> I'll try to keep this post on topic, but i think AUR can actually become 
>> the interface for this new breed of Packagers. 'noda post... 'noda day.
> 
> Isn't this sort of like what you were working on? and what Paul was working
> on with repoman?

Yeah... more like repoman with automated Continous Integration. The 
don't have to be one monolithic system, but they at least should spew 
data to and fro, and act like one Unified System.

I've taken a slight chill break on RepoBot (what i was working on), 
since I'm trying to understand that problem space a bit more so i don't 
end up redoing what repoman or pacbuild are doing.

> 
> Jason
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> arch-dev-public mailing list
> arch-dev-public at archlinux.org
> http://archlinux.org/mailman/listinfo/arch-dev-public