[Dev] [RFC] Redesign and reimplement librerelease and db-update

Michał Masłowski mtjm at mtjm.eu
Tue Apr 10 23:06:09 GMT 2012


> I like the idea, it seems feasible and easy to implement, however I
> think we should document the whole process of repo maintaining, because
> most people (me included) don't know exactly how it works.

+1, I also don't know some important parts of it.

>> My proposal is to make librerelease run a script on repo and pipe to
>> it the files to upload.
>
> +1 server site script. Just some questions, Can multiple packagers upload
> their packages at the same time? How will this be addresed?

It will work as if they were done separately in an (unspecified) order
(using the lock), unless some of them update the same packages.  In that
case only one upload would work, as if the conflicting uploads weren't
run.

> This is now addresed by uploading the packages to a «staging» area, but
> I do think we do need a way to stop outdated or same package version to
> be uploaded.

The script would make staging unnecessary.

Disabling uploads downgrading packages should be done.  I know only one
case where such uploads were done for a useful purpose
(iceweasel-libre).

> I think this require use ABS or another thing as control for deps.

It doesn't (although otherwise the script could also detect uploads
without PKGBUILDs being available).  Packages are compared with the ones
in databases being updated by the script and used by pacman.  The
xorg-server cause would be handled client-side, by users uploading all
packages that need to be updated together at once.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20120411/90bcf12a/attachment.sig>


More information about the Dev mailing list