[arch-projects] mBira project
Phrakture and I have been working on a binary repository aggregator, for personal user repositories. http://mbira.cactuswax.net Goals: 1) To help reduce the disjoint nature of personal repositories. 2) To make searching for binary packages easier. 3) Replace the PRIMAL utility 4) Potentially interface with he AUR when possible. It should be noted that mBira is not an attempt to replace the AUR. It was meant to fill the gap between the binary packages that make it into the AUR community repo, and those packages held only by users. Binary package information is culled from a personal repository, not uploaded to mbira. pkgbuilds are not dealt with in mbira, as that is what the AUR is for. Comments and questions are welcome, either here, or in the mbira forums. -- -------------------------- Bender: It was horrible! A nightmare! Fry: What happened? Bender: I dreamt I was in a place of 0's and 1's and all of a sudden... I saw a two *whimper* Fry: It's ok Bender, don't worry. There's no such thing as 2's.
Since AUR can contain unofficial PKGBUILDs, I question the utility of this? Why don't users with binary package dbs submit the packages to AUR instead. The answer, of course, will be "because they have to build the packages themselves". To this end, I think a script based on sourcepac that automatically downloads PKGBUILDs and builds them would be more useful. The script could then be integrated into pajman so that the end user wouldn't have to know the difference between getting from a pacman repo and getting from the unofficial packages. My question, really is "what is the point of personal user repositories?" Then again assuming they have a point, I think mBira is a great idea. Dusty On 6/1/05, cactus <cactus@solarblue.net> wrote:
Phrakture and I have been working on a binary repository aggregator, for personal user repositories. http://mbira.cactuswax.net
Goals: 1) To help reduce the disjoint nature of personal repositories. 2) To make searching for binary packages easier. 3) Replace the PRIMAL utility 4) Potentially interface with he AUR when possible.
It should be noted that mBira is not an attempt to replace the AUR. It was meant to fill the gap between the binary packages that make it into the AUR community repo, and those packages held only by users. Binary package information is culled from a personal repository, not uploaded to mbira. pkgbuilds are not dealt with in mbira, as that is what the AUR is for.
Comments and questions are welcome, either here, or in the mbira forums.
-- -------------------------- Bender: It was horrible! A nightmare! Fry: What happened? Bender: I dreamt I was in a place of 0's and 1's and all of a sudden... I saw a two *whimper* Fry: It's ok Bender, don't worry. There's no such thing as 2's.
_______________________________________________ arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
On 6/1/05, Dusty Phillips <buchuki@gmail.com> wrote:
Since AUR can contain unofficial PKGBUILDs, I question the utility of this? Why don't users with binary package dbs submit the packages to AUR instead.
The answer, of course, will be "because they have to build the packages themselves". To this end, I think a script based on sourcepac that automatically downloads PKGBUILDs and builds them would be more useful.
This was discussed a while back - and the answer is the same old "security". The AUR has no validation for PKGBUILDs... I could submit a PKGBUILD that has an install file that runs "rm -rf /" and the AUR will handle it just fine... an automated command to download a PKGBUILD from the AUR, and makepkg it without any checking, I can wipe your harddrive when you try to install madwifi from AUR
To me, the main reason for the continued existence of personal repositories, is that the aur only allows a single package per name. If two people want to package the same utility differently, too bad. Only one person can "own" it in the aur. Further, I custom compile several binaries (php with tidy-2.0 support for instance). If someone else wants to use my binary, then they are free to do so, instead of compiling it themselves. Those are just two examples off the top of my head, why I think personal user repositories will never go away. In all honesty, I am going to use mBira as a front end to my personal binary repository (replacing my previous use of PRIMAL). If nobody else does, then that is their choice, and they are welcome to make it. I just figured I would let people know about it, and let them make their own choices. On 6/1/05, Dusty Phillips <buchuki@gmail.com> wrote:
Since AUR can contain unofficial PKGBUILDs, I question the utility of this? Why don't users with binary package dbs submit the packages to AUR instead.
The answer, of course, will be "because they have to build the packages themselves". To this end, I think a script based on sourcepac that automatically downloads PKGBUILDs and builds them would be more useful.
-- -------------------------- Bender: It was horrible! A nightmare! Fry: What happened? Bender: I dreamt I was in a place of 0's and 1's and all of a sudden... I saw a two *whimper* Fry: It's ok Bender, don't worry. There's no such thing as 2's.
I should mention (in other forums too, probably, but you brought up the issue so you get the benefit of my spontaneous response!) is that I have been thinking about the possible merits of allowing multiple versions of the same package for some time in AUR. It's an idea that appeals to me greatly. I think the challenge will be making it simple enough to handle multiple versions of a package without it becoming overly complex. We Arch-ers like our simplicity! I'd be interested to hear more ideas about how an elegant system could be constructed that would allow multiple versions of the same package by different maintainers. What would the db look like? What would the UI look like? What would the PKGBUILD hierarchy look like? How would things get handled when you transition unsupported->community, etc? How would we explain it simply to the community? Of course, there's a lot of AUR discussion to be done. It's nearly time to sit down and have a broad-based community discussion about it and think about what's next. I'm sorry I've had so little time to devote to it recently. I'm planning to sit down with my calendar very soon to figure out some dates to propose for the Grand Unified Discussion Session. ;) - P cactus wrote:
To me, the main reason for the continued existence of personal repositories, is that the aur only allows a single package per name. If two people want to package the same utility differently, too bad. Only one person can "own" it in the aur.
Further, I custom compile several binaries (php with tidy-2.0 support for instance). If someone else wants to use my binary, then they are free to do so, instead of compiling it themselves.
Those are just two examples off the top of my head, why I think personal user repositories will never go away.
In all honesty, I am going to use mBira as a front end to my personal binary repository (replacing my previous use of PRIMAL). If nobody else does, then that is their choice, and they are welcome to make it.
I just figured I would let people know about it, and let them make their own choices.
On 6/1/05, Dusty Phillips <buchuki@gmail.com> wrote:
Since AUR can contain unofficial PKGBUILDs, I question the utility of this? Why don't users with binary package dbs submit the packages to AUR instead.
The answer, of course, will be "because they have to build the packages themselves". To this end, I think a script based on sourcepac that automatically downloads PKGBUILDs and builds them would be more useful.
On Wed, Jun 01, 2005 at 12:42:40PM -0700, cactus wrote:
To me, the main reason for the continued existence of personal repositories, is that the aur only allows a single package per name. If two people want to package the same utility differently, too bad. Only one person can "own" it in the aur.
I've always hated the idea of having a public "personal" repo containing packages with the same names as the big three repos. Here's why: Let's say cactus has a cool package that I want to try: foobar. I add cactus' repo to my pacman.conf. Then I pacman -Sy foobar and all is good. A few days later, I pacman -Syu and oh no! cactus' evil php with tidy compiled in is installed over my stock php, which I wanted! Why can't people just create php-tidy and make it provide php? Then it will work as a replacement to php (in pacman's eyes), upgrade normally, and no one will be forced to use your php version unless they wanted it. If your personal repo is actually personal and not public, this doesn't apply. Feel free to overload any packages you want from any repo you want. Just don't force your preferences on other people. That's always my response to people who want duplicate packages in AUR, add a -my-option. Make it provide and conflict if you really want to make sure only one or the other is on the system. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
This was discussed a while back - and the answer is the same old "security".
The AUR has no validation for PKGBUILDs... I could submit a PKGBUILD that has an install file that runs "rm -rf /" and the AUR will handle it just fine... an automated command to download a PKGBUILD from the AUR, and makepkg it without any checking, I can wipe your harddrive when you try to install madwifi from AUR
True that AUR doesn't verify PKGBUILDs, but at least I can look at the PKGBUILD online and decide on what it contains. A user repository sends binary packages; it could contain a package that rm -rf / in the post-install and I wouldn't even have had a chance to look before the damage was done! cactus: I didn't mean to attack personal repositories; in the case of you and phrakture, I've used both in the past and may continue to. But I don't trust anybody else to build a package properly, even if they don't mean to harm it. For me, I'd like to see all PKGBUILDs in AUR. Then I'd like to be able to view the PKGBUILD to verify the integrity (already easily done online), and then be able to run a simple program that will automatically install from AUR without me having to manually download the pkg and makepkg it... If the pkg is in somebody's repo, I have to edit pacman.conf, and personally, I like to keep that as simple as possible... I hate adding repositiories so I can download just one or two programs from them. But that might just be me. I'm remembering days when I had a loooooooooooong list of apt-get sources that took literally an hour to update on dialup... lovely thing about arch is I don't even remember the file that apt-get sources are stored in! :-) Anyway, I hijacked your topic here... I recall phrakture had a script to grab PKGBUILDs from AUR, so it shouldn't be hard for me to extend this to automatically build too. Dusty
For me, I'd like to see all PKGBUILDs in AUR. Then I'd like to be able to view the PKGBUILD to verify the integrity (already easily done online), and then be able to run a simple program that will automatically install from AUR without me having to manually download the pkg and makepkg it... If the pkg is in somebody's repo, I have to edit pacman.conf, and personally, I like to keep that as simple as possible... I hate adding repositiories so I can download just one or two programs from them. But that might just be me. I'm remembering days when I had a loooooooooooong list of apt-get sources that took literally an hour to update on dialup...
[snip]
Anyway, I hijacked your topic here... I recall phrakture had a script to grab PKGBUILDs from AUR, so it shouldn't be hard for me to extend this to automatically build too.
The big problem with cherry-picking packages is that you never get updates. Even with a phrakture+srcpac+magic set of scripts, updating won't be as robust as pacman (you'd essentially be rewriting all the update logic from pacman). Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
On Wed, Jun 01, 2005 at 02:29:37PM -0500, Aaron Griffin wrote:
On 6/1/05, Dusty Phillips <buchuki@gmail.com> wrote:
Since AUR can contain unofficial PKGBUILDs, I question the utility of this? Why don't users with binary package dbs submit the packages to AUR instead.
The answer, of course, will be "because they have to build the packages themselves". To this end, I think a script based on sourcepac that automatically downloads PKGBUILDs and builds them would be more useful.
This was discussed a while back - and the answer is the same old "security".
The AUR has no validation for PKGBUILDs... I could submit a PKGBUILD that has an install file that runs "rm -rf /" and the AUR will handle it just fine... an automated command to download a PKGBUILD from the AUR, and makepkg it without any checking, I can wipe your harddrive when you try to install madwifi from AUR
There's a subtlety here that I think you've missed. The AUR can have contributions from anyone, with very weak-grained (opposite of fine-grained) control over who's packages you see. Essentially it'd be one huge personal repo that anyone could submit to. You have to trust everyone in existence if you trusted a random package from AUR. A personal repo is usually run by a single person. It's fairly easy to say if you trust that one person's packages or not. By using a personal repo, I'm implicitly trusting the maintainer of that repo. By using a automatic-package-installing AUR, I'm implicitly trusting anyone with enough brains to create an AUR account. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
A personal repo is usually run by a single person. It's fairly easy to say if you trust that one person's packages or not.
By using a personal repo, I'm implicitly trusting the maintainer of that repo. By using a automatic-package-installing AUR, I'm implicitly trusting anyone with enough brains to create an AUR account.
Yes, but using a semi-automatic package-installing AUR allows me to install from the PKGBUILD after I've reviewed it for saneness. The thing I don't like about binary repos is having to maintain them all in pacman.conf... when it gets down to one repo per package, that sucks. Dusty
On Wed, Jun 01, 2005 at 08:20:57PM -0600, Dusty Phillips wrote:
A personal repo is usually run by a single person. It's fairly easy to say if you trust that one person's packages or not.
By using a personal repo, I'm implicitly trusting the maintainer of that repo. By using a automatic-package-installing AUR, I'm implicitly trusting anyone with enough brains to create an AUR account.
Yes, but using a semi-automatic package-installing AUR allows me to install from the PKGBUILD after I've reviewed it for saneness. The thing I don't like about binary repos is having to maintain them all in pacman.conf... when it gets down to one repo per package, that sucks.
Dusty
Right, but I wasn't talking to you... or about that. I was responding about the "security" answer... Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
participants (5)
-
Aaron Griffin
-
cactus
-
Dusty Phillips
-
Jason Chu
-
Paul Mattal