Suggestion for new package management scheme

LavaPunk · 2004-05-02 20:15:49

A wiki might be a good second step. First we set up a forum system in about 15 minutes. Then we work out a more functional wiki system in a couple of weeks. After that we will have learned from the mistakes and might be able to set up some sort of web based or testpkg based script.

I'm not sure why we would need that forum set up in 15 minutes, might as well just wait and get it done correctly to start with, I don't see any reason to jump on this too quickly as you would suggest. The only other thing I wonder is you keep referring to "we" but who is we? Are we asking the already overworked devs to set this up or what?

contrasutra · 2004-05-02 20:28:44

LavaPunk wrote:

I'm not sure why we would need that forum set up in 15 minutes, might as well just wait and get it done correctly to start with, I don't see any reason to jump on this too quickly as you would suggest. The only other thing I wonder is you keep referring to "we" but who is we? Are we asking the already overworked devs to set this up or what?

I agree completely. We're not trying to find a temporary solution, we're trying to find a proper solution that we can use and expand. No one will die if this doesn't get resolved this week.

The solution has to be as simple as possible, and using multiple applications isn't simple. With the forum, we'd need an FTP server and a testpkg script to go along with it. That's 3 things,

Remember, any submitted PKGBUILDs are just to help people who can't create PKGBUILDs themselves. Really, the system is just about choosing which pkgs the developers should maintain. I've built hundreds of PKGBUILDs, and 99% of them are really easy (hell, if I can do it at all...). It's not like the developers need any help creating the PKGBUILDs.

So yeah, that's why I still don't think we need a place to submit PKGBUILDs. We just need a voting system. Believe me, 80% of the PKGBUILDs in INCOMING have to be thrown out completely and be redone. Its more trouble than it's worth (that's where the problems started).

Zephirias · 2004-05-02 20:54:48

You're making some valid points, and you're right about the patience. I think for this, however, we should have a closed Forum for anyone that is or is planning to help with the project to discuss the progress (if there isn't already), and then we have a public Forum for the voting. However, I still support my idea for a web/program based package management system.

contrasutra · 2004-05-02 21:13:55

Dude, there's been a private forum. You weren't invited.

Zephirias · 2004-05-02 21:45:30

contrasutra wrote:

Dude, there's been a private forum. You weren't invited.

:cry:

rasat · 2004-05-03 07:29:17

contrasutra wrote:

I agree completely. We're not trying to find a temporary solution, we're trying to find a proper solution that we can use and expand. No one will die if this doesn't get resolved this week.

The incoming issue is not new, started last November. When using the "New Package" forum, we are here not speaking about a "temporary solution" but as a temporary place because it fills many ideas what have been discussed.

The solution has to be as simple as possible, and using multiple applications isn't simple. With the forum, we'd need an FTP server and a testpkg script to go along with it. That's 3 things

Everyone will be glad if the 3 applications are in one website (I doubt its possible). Even if succeed, there is no guaranty many users will use the website. Already to get users to use Wiki, what to say about the "Arch Package Review Page", is not easy when everyone is familiar with the Forum only. Let us be practical as far as possible.

Believe me, 80% of the PKGBUILDs in INCOMING have to be thrown out completely and be redone. Its more trouble than it's worth (that's where the problems started).

You are maybe correct about the condition of the PKGBUILDs. Myself went through most of the packages adding description and comparing with freshmeat.net, 80% are good applications. Here we can see why the vote become important . This cannot be voted with a "vote click" alone but also requires to have place for comments.

Mr Green · 2004-05-03 10:23:11

How do you get invited to the Secret Forum :?:

Mr Green

i3839 · 2004-05-03 14:47:52

I like sweiss' idea the most.

Why make a weird vote system? All the "voting" you need is the number of downloads of a certain package, nothing more. Especially if contrasutra is right, then it's just a matter of putting all new (more or less working) packages automatically in some repository, e.g. testing/unstable, and then purge the packages that don't have enough downloads after a month or so. That seems to be all the selection you need. Debugging and making sure that the package works is something else than deciding if it becomes official or not.

You could even let pacman and the search function on the website log all the requests for non-existent packages, so that you know for which packages there is demand (and which typos are made most often).

There should always be a centralized place for non-offical (binary+PKGBUILD) packages, no matter what system you have. This doesn't have to be a repository, the main point is that users can find it easily. All rejected packages can be dumped at this place.

It seems that the developers can't handle all the work, and that perhaps there is even demand for more devs, but we don't know, because we hear nothing about that. If Arch really needs more developers then it should make that public and big chance that there will be enough people volunteering.

mcubednyc · 2004-05-03 16:49:18

contrasutra wrote:

I've built hundreds of PKGBUILDs, and 99% of them are really easy (hell, if I can do it at all...). It's not like the developers need any help creating the PKGBUILDs.
Believe me, 80% of the PKGBUILDs in INCOMING have to be thrown out completely and be redone. Its more trouble than it's worth (that's where the problems started).

Isn't there a bit of a contradiction here? On the one hand, you're saying PKGBUILDs are trivially easy; on the other, that 80% have to be thrown out, presumably because they aren't built correctly. If they are so easy, why are so many unusable?

rasat · 2004-05-04 05:56:16

Mr Green wrote:

How do you get invited to the Secret Forum :?:

Nothing secret. The idea was generated from topic "Running Arch LInux: Development User". It was announced there. Instead of discussing different programming languages only, this foum does projects as well. Current work is ADM (Arch Display Manager)
http://bbs.archlinux.org/viewtopic.php?t=3302

PS.
Lot of good ideas are suggested in the Arch Forum, but don't get implemeneted when waiting for Arch to do the work. The alternative is to setup the idea(s) on another server where anyone can join. At the same time its an example what the idea(s) was all about. Gets tested and gets to know if useful / practical.... the Linux way

potentials · 2004-05-04 15:47:02

The problem is that there's no centralized place for users to contribute packages. There's the incoming directory on the ftp server, the "New Packages" forum , the AIR and the suggested testpkg. One might upload a package or PKGBUILD to the ftp server and not announce in the forum so it goes unnoticed, beside that the "incoming" is already a mess because there's no possibe way to categorize and organize it, that's why I think we must get rid of the "incoming" as we know today.

Both AIR and testpkg eliminate the need of the incoming directory where people directly upload there PKGBUILDs (it is already almost agreed on that no binary packages should be uploaded).Why not combine testpkg and AIR such that both provide the exact same functionality? ( eventually AIR will be a web interface for teskpkg that does exactly what testpkg does but ofcourse without building packages but since AIR is currently more developed than testpkg it is the other way around, testpkg is the one that must cope with AIR).

Few points to add :

1)AIR/testpkg might provide the suggested voting system

2)AIR/testpkg must provide the PKGBUILDs and all other necessary scripts, providing a link to the thread in the "New Pakages" forum as AIR currently does is not convenient at all.

3)AIR might include a discussion section and so we might not need the "New Packages" forum at all, that way we'll have a centralized place where packages are submitted and discussed. If not a link to the discussion thread on the "New Packages" forum will do it, but the link must be in the "Discussion" entry and not in the "PKGBUILD" entry as it is now.

punkrockguy318 · 2004-05-05 19:48:21

Okay, here are some of my points.

*** There should be one centralized place for incoming packages. This way, people know where to put their packages, and they don't need to submit them to multiple places.

*** There should be one centralized respitory for user contributed packages. We don't want a lot of personal respitories (like debian/suse), or a lot of TURs. There needs to be one place. An unofficial user maintained respitory would work.

*** Packages should be submitted through a wiki-like interface. There is a voting system with this wiki post. If a user has success, he votes success on the wiki. If the package doesn't work, or has more dependencies, he voes failure on the wiki, and see's if he can modify the wiki to make it work. Once the PKGBUILD is mostly sucsessful, the package and the PKGBUILD is added to the unofficial respitories. From there, the devs can pick out important packages and add to the official respitories if they see fit (or if it's voted into the respitories)

*** The above wiki would be in categorized form, instead of a mosh (like incoming)

*** This would be much different from incoming. Instead of the dev's going through a bunch of unorganized crappy PKGBUILDs, they can go through quality tested stable package respitory.

*** Incoming, staging and TURs would go away.

*** An older respitory should be added - for outdated packages. These packages will be removed from the official ones, and put there. An team of package maintainers could manage these.

Here's a visual display...

User's PC -> Incoming PKGBUILD Wiki -> Users fix PKGBUILD and perfect them -> Unofficial -> (through voting or dev's) current/extra -> (in many years) Old

These are just a lot of idea's. I know nothing is going to happen overnight, but that's just my plan of what would work well. The first step is to create the wiki system, then other things can be accomplished. It work well because A) We wouldn't have crappy unofficial respitories, they would be quality ones B) One central place to submit packages C) Dev's won't be doing the things that the users can do.
What do you guys think of this idea? How do you agree/disagree for each point? I think this would make an organized stable change from incoming. What do you think?

Zephirias · 2004-05-05 23:02:15

I like what you're saying, punkrockguy. It makes a lot of sense, and a centralized base for packages that runs like that would be a good idea, IMO.

sarah31 · 2004-05-06 03:56:11

i don't have time to read the five pages of stuff here anyone wanna provide a synopsis. personally other than redoing incoming there is no need to rethink the repo setup. there has been and always will be a shortage of package maintainers. that being said that should not stop the effort to obtain more. at the same time a specific in writing standard, complete with unmentioned "rules", for package building should be set up and a application acceptance standard set.

perhaps take a look at how other large distros handle so many packages. crux has a particularily good system imho. they have a very slim set of packages for their base then after that iti is basically user controlled. mind you it is more a source distro and not a premade binary distro. but it could provide some ideas.

Dusty · 2004-05-06 04:09:20

sarah31 wrote:

i don't have time to read the five pages of stuff here anyone wanna provide a synopsis.

Why bother, it's the same old thing? Lot's of suggestions and disagreement...

personally other than redoing incoming there is no need to rethink the repo setup.

more suggestions and disagreement.

at the same time a specific in writing standard, complete with unmentioned "rules", for package building should be set up and a application acceptance standard set.

something like that is in the works.

Dusty

sarah31 · 2004-05-06 04:14:35

Dusty wrote:

something like that is in the works.

sounds like rumor and inneuendo

Dusty · 2004-05-06 23:17:38

sarah31 wrote:

Dusty wrote:
something like that is in the works.
sounds like rumor and inneuendo

no, a rumor would start with "I heard tell..." That's worded like a fact.

Dusty

Mr Green · 2004-05-07 12:29:42

I want a package system like Crux

For too long I have just used Pacman to do all the hard work (it makes you lazy)

With so many packages you need more maintainers

Or let the user get (or build it!) themselves

pacman should be for base pkgs (system,libs etc...)

I do not know about anyone else but I want to be able to compile my kernel/pkgs

I will not learn anything doing it the easy way .... if it breaks which it does often, then I will ask for help....

So cut the number of pkgs (decided by the maintainers who do all the work)

Mr Green :cry:

sweiss · 2004-05-07 13:59:08

Mr Green wrote:

I want a package system like Crux
For too long I have just used Pacman to do all the hard work (it makes you lazy)
With so many packages you need more maintainers
Or let the user get (or build it!) themselves
pacman should be for base pkgs (system,libs etc...)
I do not know about anyone else but I want to be able to compile my kernel/pkgs
I will not learn anything doing it the easy way .... if it breaks which it does often, then I will ask for help....
So cut the number of pkgs (decided by the maintainers who do all the work)
Mr Green :cry:

I don't know about you, but I chose Arch because of the freedom it gives me. As a user of a relatively old computer I cannot compile too much, and so I chose Arch which provides both binary packages and the ABS system in case you want to compile something on your own.

Compiling all the things yourself will simply turn pacman useless, as a lot of functions it provides will not be used as there's no reason to.

Also, you normally don't learn much from compiling, most of the times it's just configure, make, make install. On another case, some people prefer not to learn or already know but do not want to mess around with compiling advanced software, as the entire purpose of pacman is to make our lives easier, at least that's the way I see it.

If you do wish to learn, there's always ABS with all the PKGBUILDs.

Dusty · 2004-05-07 15:38:28

Mr Green wrote:

I want a package system like Crux

Then use Crux. :-P

I do not know about anyone else but I want to be able to compile my kernel/pkgs

Then use Gentoo. :-P

I will not learn anything doing it the easy way .... if it breaks which it does often, then I will ask for help....

Then use Linux From Scratch. :-P

I think you gotta love a distro that can be substituted for any and all of the above. So easy to satisfy everybody... if only they would be easierto satisfy. :-D

Dusty

Mr Green · 2004-05-07 16:29:52

I knew it was a bad idea posting on this thread ....but I will do anything to get flamed...

Maybe you are right I should use Crux ...

Gentoo been there done that did not want the T-shirt

emmm Ark linux sounds nice (a nice GUI distro)

No packages should be based on there downloads not voted on by users ....some pkgs will have a high download figure system/base/libs others will be very low er like Eterm

PKGBUILDs take up far less room & I would havethought be less of an impact on bandwidth

Mr Green :twisted:

note to self stop reading ESR...

tbuitenh · 2004-05-08 20:27:43

Just some thoughts from a user, many of this has probably already been said.

Managing developers is like herding cats... So here's my advice: split up!

I use Arch because it is so up-to-date, and I like pacman and abs. I think it is most important that the devs maintain the stuff that everyone needs. I would move extra out of Arch and split it into multiple mostly independent distro's - Arch Server, Arch Gnome, Arch KDE, etc etc...
This would also solve a typical binary distro problem (a bit):
A needs C with option 1
B needs C with option 2
C with 2 needs D, C with 1 doesn't.
I install A and get D, which I don't want...
If someone who uses the same sub-arch as I do wants option 2, he can use abs.

Adding extra layers before or instead of incoming is a bad idea, it will make Arch less up-to-date. Voting will make the time before something new and cool is included even longer.

Summary: If you need more devs but are not able to manage them, then don't manage them.

I'm sure there are lots of users like me, who would love to help out, but are scared away by too much chaos on one side, and too much order on the other (I don't want to be a TU).

tbuitenh · 2004-05-08 20:33:33

Hey, the KDE group could make themselves a really nice installer, and noone would be forced to use it ;-)

There's a short way to say everything I said: I want a binary distro that contains everything I need, in the latest versions, and works perfectly. With a huge distribution like debian, this is not possible. Don't become a second debian.

arch_newb · 2004-05-10 13:41:29

Hi all,
I tend to think that arch should make it easy for users to access what ever software they need. From a users perspective I find pacman to be an excellent way of installing packages but if it only works for the base system or selected packages Arch linux will become less appealing to a large group of users (both current and potential). I would imagine that getting more package maintainers to contribute would not be a major problem if arch continues on its current path.
Cheers
arch_newb

Mr Green · 2004-05-11 10:51:50

I think you speak the truth Arch is a victim of its own success

but our efforts much lay with making things better ....

more maintainers is the answer but users must help if they can....

As the the tree grows it need stronger roots.....

Mr Green

Arch Linux

#51 2004-05-02 20:15:49

Re: Suggestion for new package management scheme

#52 2004-05-02 20:28:44

Re: Suggestion for new package management scheme

#53 2004-05-02 20:54:48

Re: Suggestion for new package management scheme

#54 2004-05-02 21:13:55

Re: Suggestion for new package management scheme

#55 2004-05-02 21:45:30

Re: Suggestion for new package management scheme

#56 2004-05-03 07:29:17

Re: Suggestion for new package management scheme

#57 2004-05-03 10:23:11

Re: Suggestion for new package management scheme

#58 2004-05-03 14:47:52

Re: Suggestion for new package management scheme

#59 2004-05-03 16:49:18

Re: Suggestion for new package management scheme

#60 2004-05-04 05:56:16

Re: Suggestion for new package management scheme

#61 2004-05-04 15:47:02

Re: Suggestion for new package management scheme

#62 2004-05-05 19:48:21

Re: Suggestion for new package management scheme

#63 2004-05-05 23:02:15

Re: Suggestion for new package management scheme

#64 2004-05-06 03:56:11

Re: Suggestion for new package management scheme

#65 2004-05-06 04:09:20

Re: Suggestion for new package management scheme

#66 2004-05-06 04:14:35

Re: Suggestion for new package management scheme

#67 2004-05-06 23:17:38

Re: Suggestion for new package management scheme

#68 2004-05-07 12:29:42

Re: Suggestion for new package management scheme

#69 2004-05-07 13:59:08

Re: Suggestion for new package management scheme

#70 2004-05-07 15:38:28

Re: Suggestion for new package management scheme

#71 2004-05-07 16:29:52

Re: Suggestion for new package management scheme

#72 2004-05-08 20:27:43

Re: Suggestion for new package management scheme

#73 2004-05-08 20:33:33

Re: Suggestion for new package management scheme

#74 2004-05-10 13:41:29

Re: Suggestion for new package management scheme

#75 2004-05-11 10:51:50

Re: Suggestion for new package management scheme

Board footer