On 9/25/07, Jürgen Hötzel wrote:

On Tue, Sep 25, 2007 at 01:14:11PM -0500, Aaron Griffin wrote:

...

This was brought up in a previous thread started by Damir, regarding committing a package to more than one repo at a time.

I think it'd be more beneficial for us to split of architecture independent packages, just to eliminate redundancy. Python modules, scripts, etc they'd all fit here.

Does anyone have an opinion on the matter? I think adding a arch=(none) or arch=(all) setup would be a good idea, BUT there might be a lot of other things that need to be changed.

What about arch-dependent repositories:

core-noarch core-i686 core-x86_64

extra-noarch extra-i686 extra-x86_64

This doesn't require architecture handling code in pacman. Just another package repository move ;-))

That's what I was thinking too, though I don't think we have anything that'd fit in core.... BUT extra has a lot. The only "problem" is that we have this unwritten rule that dependencies don't cross repos - we'd be breaking this rule there. Now this is fine with me, but I know others like that rule.

On 9/25/07, Dan McGee wrote:

Wait, now that I'm thinking, it might exist in the PKGINFO but pacman never explicitly checks it...

Yeah, I don't know if we ever do a "pkg arch == running arch" check. The only time it'd matter is with the filename.

On 9/25/07, Dan McGee wrote:

On 9/25/07, Aaron Griffin wrote:

...

On 9/25/07, Dan McGee wrote:

...

Wait, now that I'm thinking, it might exist in the PKGINFO but pacman never explicitly checks it...

Yeah, I don't know if we ever do a "pkg arch == running arch" check. The only time it'd matter is with the filename.

Worth reviving? It was on the back-burner but it is something that has bugged me. If we do this, we could easily do some stuff for arch-generic packages around the same time.

http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=a384a2feb2e...

Ok, yeah let's revive this, BUT, lets get at least a majority opinion on arch independent repos, before we attack this. Can I get a simple +1/-1 for this, before Dan and I take it too far? Thanks, Aaron

On Tue, 25 Sep 2007 14:49:13 -0500 "Aaron Griffin" wrote:

On 9/25/07, Dan McGee wrote:

...

On 9/25/07, Aaron Griffin wrote:

...

On 9/25/07, Dan McGee wrote:

...

Wait, now that I'm thinking, it might exist in the PKGINFO but pacman never explicitly checks it...

Yeah, I don't know if we ever do a "pkg arch == running arch" check. The only time it'd matter is with the filename.

Worth reviving? It was on the back-burner but it is something that has bugged me. If we do this, we could easily do some stuff for arch-generic packages around the same time.

http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=a384a2feb2e...

Ok, yeah let's revive this, BUT, lets get at least a majority opinion on arch independent repos, before we attack this.

Can I get a simple +1/-1 for this, before Dan and I take it too far?

+1 for architecture independence

On 9/26/07, Roman Kyrylych wrote:

2007/9/26, Travis Willard :

...

On Tue, 25 Sep 2007 14:49:13 -0500 "Aaron Griffin" wrote:

...

On 9/25/07, Dan McGee wrote:

...

On 9/25/07, Aaron Griffin wrote:

...

On 9/25/07, Dan McGee wrote:

...

Wait, now that I'm thinking, it might exist in the PKGINFO but pacman never explicitly checks it...

Yeah, I don't know if we ever do a "pkg arch == running arch" check. The only time it'd matter is with the filename.

Worth reviving? It was on the back-burner but it is something that has bugged me. If we do this, we could easily do some stuff for arch-generic packages around the same time.

http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=a384a2feb2e...

Ok, yeah let's revive this, BUT, lets get at least a majority opinion on arch independent repos, before we attack this.

Can I get a simple +1/-1 for this, before Dan and I take it too far?

+1 for architecture independence

+1.

Note that we don't need any noarch repo or something like this! We should just do this: 1) modify {core,extra,community}pkg to tag CVS files for noarch packages as CURRENT and CURRENT64 at the same time 2) add noarch packages to i686 and x86_64 .db.tar.gz files at the same time (modify all needed scripts) 3) modify makepkg to understand arch=('any') (or 'all', feel free to name it) and make -any.pkg.tar.gz files 4) modify our web backend (we need to do this anyway because of x86_64 support) No changes to pacman needed.

This is a good point, I didn't think about it. Pacman 3.0 lists actual filenames in the DBs (so a package could actually be named "lol.wtf" if you wanted it to). If we simply add special handling in the scripts (makepkg, db scripts, etc) for -any/-all packages, we can solve this with little changes. Dan and I will look into this - could someone add a ticket to flyspray as a reminder - assign it to Dan and myself. Thanks. --Aaron

Am Fri, 28 Sep 2007 11:07:21 +0300 schrieb "Roman Kyrylych" :

2007/9/27, Aaron Griffin :

...

...

Note that we don't need any noarch repo or something like this! We should just do this: 1) modify {core,extra,community}pkg to tag CVS files for noarch packages as CURRENT and CURRENT64 at the same time 2) add noarch packages to i686 and x86_64 .db.tar.gz files at the same time (modify all needed scripts) 3) modify makepkg to understand arch=('any') (or 'all', feel free to name it) and make -any.pkg.tar.gz files 4) modify our web backend (we need to do this anyway because of x86_64 support) No changes to pacman needed.

This is a good point, I didn't think about it. Pacman 3.0 lists actual filenames in the DBs (so a package could actually be named "lol.wtf" if you wanted it to). If we simply add special handling in the scripts (makepkg, db scripts, etc) for -any/-all packages, we can solve this with little changes.

Dan and I will look into this - could someone add a ticket to flyspray as a reminder - assign it to Dan and myself.

Done: http://bugs.archlinux.org/task/8153

Please make sure you don't force us to use the devtools! It should be possible to do the build process without any tools. I always had the problem that devtools didn't support pkgdest from makepkg.conf and i couldn't set any bandwidth limit. So i cannot use them. I prefer to do everything at commandline myself and want to use any tool (e.g. for ftp uplaod) i want. And please keep in mind that simplicity/KISS is one our (still not defined) goals. That also came up when we were discussing about splitted packages and unreadable pkgbuilds. I don't think it's important to have noarch implemented right now as one the first new features. A buildserver and beeing more multiarch capable (cvs move, website/feeds, maintainership) seems more important to me. But I'm not against it at all if you can implement it easy. Andy

On 9/28/07, Andreas Radke wrote:

I don't think it's important to have noarch implemented right now as one the first new features. A buildserver and beeing more multiarch capable (cvs move, website/feeds, maintainership) seems more important to me. But I'm not against it at all if you can implement it easy.

As a different issue here. I feel it's important. I am one of our pacman developers. So most likely this will get done. See, here's the thing I see from a lot of developers here. You guys don't realize this is open source. Most of the open source development is of the "scratch an itch" kind. I find Z important, so I implement Z. If you think that pacbuild is important, then by golly, work on pacbuild. This is how we SHOULD be working, but I see nothing of the sort. Instead I see people saying "hey you guys should work on what I find important". This is not only _not_ in the spirit of open source, but it is rude. Frankly, if I write some code and get, in response, "you should have been working on feature A instead", it makes me angry. It makes me feel unappreciated. It makes me lose motivation. So please. We need to stop this mentality of "don't do X, Y is more important". The reason these threads are brought up is NOT so we can go off on tangents and talk about other things. They exist so we can talk about the topic.

Aaron Griffin wrote:

On 9/25/07, Dan McGee wrote:

...

On 9/25/07, Aaron Griffin wrote:

...

On 9/25/07, Dan McGee wrote:

...

Wait, now that I'm thinking, it might exist in the PKGINFO but pacman never explicitly checks it... Yeah, I don't know if we ever do a "pkg arch == running arch" check. The only time it'd matter is with the filename. Worth reviving? It was on the back-burner but it is something that has bugged me. If we do this, we could easily do some stuff for arch-generic packages around the same time.

http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=a384a2feb2e...

Ok, yeah let's revive this, BUT, lets get at least a majority opinion on arch independent repos, before we attack this.

Can I get a simple +1/-1 for this, before Dan and I take it too far?

+1, but we must make sure we don't end up with separate *source* repos at any implementation level. e.g. [extra] should be said to contain a set of packages, and each package may be built for i686, x86_64, and/or our new "noarch" architecture and put in *binary* repos sorted by architecture. Otherwise we won't be able to maintain any coherence of the distribution across architectures, and they will grow into entirely separate beasts. - P "The world is a jungle in general, and the architecture game contributes many animals." -- paraphrased from RFC 826, the ARP specification

BUT extra has a lot. The only "problem" is that we have this unwritten rule that dependencies don't cross repos - we'd be breaking this rule there.

I think this is a separate "problem". That rule had to do with when you had a repository hierarchy (current, extra, unstable/community). An all/none/any repository is more like an additional repository, not one in a hierarchy. Jason