[debexpo-devel] Concept work nearly done

Christoph Haas email at christoph-haas.de
Thu May 22 10:43:09 CEST 2008


On Donnerstag, 22. Mai 2008, Jonny Lamb wrote:
> On Wed, May 21, 2008 at 05:44:11PM +0200, Christoph Haas wrote:
> > Does PPA refer to the "personal package archive" software? I think I
> > fail to understand what it's used for. To store source and binary
> > package information? In that case I could imagine a table hierarchy
> > like this:
> >
> > packages -> package_versions -> package_source -> package_files
> >                              -> package_binary -> package_files
> >                              -> package_comments
>
> I was under the assumption that there were going to be two
> repository-types in debexpo. One would be the main repository that
> mentors.debian.net would use. The other (the PPAs) would be optional
> and each user could have a personal repository. I assumed that the QA
> checks, package commenting, etc. which is obviously very important in
> the main repo (for mentors) would not take place in these PPAs. When I
> think about it though, it seems a little flawed.

Actually I would simplify the whole thing. What if we do not distinguish 
between personal archives and public archives? I would rather think of 
debexpo as a package marketplace. Everybody is free to upload, try, 
download, comment on and sponsor any other package. My personal intention 
was to have a software that is flexible enough that it works for 
mentors.debian.net as well as a personal package archive. But I don't 
think there will be a site that is used for sponsoring (like 
mentors.debian.net) and at the same time provides personal non-public 
archives that do not need to have the packages checked (plugins disabled). 
How debexpo works on a certain deployment should be controlled through 
variables in the INI files. Like whether binary uploads are allowed - or 
only source uploads. Whether the comment feature is enabled. Which plugins 
are run on uploaded packages. Etc. Examples:

mentors.debian.net:
- All QA plugins enabled
- Commenting enabled
- Source packages enabled
- Binary packages disabled

debian-packages.my-university.de:
- QA plugins disabled
- Commenting disabled
- Source packages enabled
- Binary packages enabled (auto-built from the source packages)

backports.debian.net:
- Several QA plugins enabled
- Source packages enabled
- Binary packages enabled
- Commenting disabled

www.debian-multimedia.org:
- QA plugins diabled
- Source packages disabled
- Binary packages enabled
- Commenting disabled

And even on mentors.debian.net a certain package maintainer can give other 
people this URL to his "personal" packages:
 http://mentors.debian.net/packages/jonny@lamb.info

That URL would just show the packages from this user. Perhaps it can even 
be made apt-get'able per-user so that the above URL can be used by other 
users to just access packages of this specific uploader. E.g.:

   deb-src http://mentors.debian.net/packages/jonny@lamb.info sid main

My point is: consider not seperating the needs of mentors.debian.net and 
the PPA. I think that 80% of their needs are the same. And if 
mentors.debian.net needs some extra check plugins then let's hack them in 
(or let others do that through the plugin API). The basis for everything 
is a web-based repository system that can host (source/binary) packages. 
All the other behavior can be customized.

I hope you get my point. I'm confident that it makes things way simpler. 
Make things generic and let the system administrator of each instance of 
debexpo choose what behavior is needed. Does that make sense?

Cheers
 Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://workaround.org/pipermail/debexpo-devel/attachments/20080522/d7479acd/attachment-0001.pgp 


More information about the debexpo-devel mailing list