[crux-devel] How to speed up CRUX maintenance?
Jose V Beneyto
sepen at mikeux.dyndns.org
Fri Dec 11 09:01:17 UTC 2009
Victor Martinez wrote:
> Clemens Koller wrote:
>> Hello, Richard!
>> Richard Pöttler schrieb:
>>> Am 10.12.2009 21:25, schrieb Clemens Koller:
>>>> What about adding something like prt-get --push <portname>
>>>> that a newly created / updated port will be published
>>>> to some mailing list for review and inclusion into i.e. contrib?
>>> You think about something like git-format-patch and git-send-email? ;)
>> Yes, for example. It seems like a very good idea to use git. But how
>> many users are using git and push their changes nowadays? Why isn't this
>> part of the default setup?
Maintainers from core, opt, xorg, contrib, kde, xfce, all x86_64's
and etc. are using git. See http://crux.nu/gitweb/
Since CRUX was made as a lightweight distro I don't think git should be
the default setup, but that doesn't means that you can't install git on
>>>> I think it would be much better to centralise the repositories to get
>>>> opt and contrib more up-to-date instead of everybody is doing
>>>> his/her own
>>>> thing. What do you think?
>>> Somehow I don't get, how you came to the conclusion, that you want
>>> to centralize all ports, but don't think, that it is worth to
>>> publish your own ports.
>> In my point of view, something is missing in the default CRUX way:
>> Feedback to
>> one _central_ place.
> I think the point is to get feedback, doesn't really matter if it's
> centrilzed or not. There are lot of ways to talk with maintainers,
> email adresses, irc and of course the bugtracker.
>>> Imho it is pretty simple to become a conrtib maintainer to make your
>>> ports available for everyone.
>> If it's so simple, can it become a default for everyone?
>> A simple way to push changes to i.e. contrib (via a list and via
>> review by
>> some list members) would imo motivate more people to contribute.
Just file a contrib application to push changes to contrib but first, to
keep the quality of contrib
high, you should maintain an repository for a while (2-6 month) to get
used to packaging, following upstream sources etc. All the other
maintainers will review your ports, and if they decide to
trust your work you'll become a maintainer. (Please see
I would not image if a new user updates a Pkgfile and because of his
lack of experience he push
something wrong (like missing the $PKG variable) or maybe malware, etc.
IMHO people should trust you before push packages.
>> This could focus development more to one 'upstream' repository and
>> avoid more diversification of the ports.
> Duplicated ports in personal repositories I think are used to specify
> personal options to a port. The "official" repositories must fill the
> basic options, and I think that's the reason why there are lot of
> duplicates. When the only difference between official ports and
> personal ports is a version bump, then there is a lack of comunication
> (exists the possibility about a security reason too, or may be
> dependencies with other ports with a unique version) but the way to go
> must be to talk with maintainer's port and advice about a new version.
>> There need be an instance to review these changes - a list.
>> A clearly visible version and timestamp could make it very clear which
>> port is old an could benefit from an update.
>> Example: I need to update qt4 because I want to find out if the newest
>> qtcreator can be used for sw development for a project.
>> That is: qt-4.6.0 and qtcreator-1.3.0
>> What do you do? Search the portdb for 'qt'...
>> You will get some hits: 3x qt4, qt-creator and qtcreator
>> from different collections. (Some work was done more than once.)
>> Now, you need to find and decide which qt thing is good for you.
>> Here, the mess starts:
> You can verify if the port exists in an official repo and talk
> directly to the maintainer. Your point can be discussed and reasoned.
> I think the best way to maintain a port is to let it to one person,
> and this doesn't mean that a port update can't be talked. We finish in
> the same point, communication between maintainers and users.
>> You cannot check all the Pkgfiles in one place. -> :-( You have to
>> check the Pkgfiles manually to find out which version can be
>> preferrably used for an update. -> :-(
As nipuL says, he's working on portdb-ng, and for what I know he has
created a great CLI tool (pdb)
to get all the stuff you need from the portdb. Maybe you could
contribute with testing it.
>> You have to check the Pkgfiles manually to find out which
>> version can be preferrably used for an update. -> :-(
>> You have to clone the whole collection if it's using
>> rsync just to be able to find out the version of one port... -> :-(
> You can get the port when using rsync, there is a command in the
> portdb to get only the port instead of getting the entire collection.
You can use the http command too. And that is also improved in the
You can use other alternatives to have a meta collection of ports.
I'm developing 'mpup' (a meta-collection driver script for ports).
Tests, ideas and help are welcome
Jose V Beneyto | http://mikeux.dyndns.org
Jose V Beneyto | http://mikeux.dyndns.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the crux-devel