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.
For instance, pacman doesn't handle this case right now, we'd need code in there, etc
Please discuss, I haven't put much thought into it.
Thanks, Aaron
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 ;-))
Jürgen
On 9/25/07, Jürgen Hötzel juergen@hoetzel.info 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, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/25/07, Jürgen Hötzel juergen@hoetzel.info 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.
This sidestepped the problem from earlier with pacman not liking it. Each package name now has either/both a hardcoded arch in the package name, or in the .PKGINFO file itself, I believe. Thus you won't be able to install packages built this way on other architectures, even if you rename it to make it happy. This will need some actual machinery in pacman and makepkg to make it happen, I believe.
Wait, now that I'm thinking, it might exist in the PKGINFO but pacman never explicitly checks it...
-Dan
On 9/25/07, Dan McGee dpmcgee@gmail.com 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, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com 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...
-Dan
On 9/25/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/25/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com 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, Sep 25, 2007 at 02:49:13PM -0500, Aaron Griffin wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/25/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com 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
Jason
On Tue, 25 Sep 2007 14:49:13 -0500 "Aaron Griffin" aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/25/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com 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
2007/9/26, Travis Willard travis@archlinux.org:
On Tue, 25 Sep 2007 14:49:13 -0500 "Aaron Griffin" aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/25/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com 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.
On 9/26/07, Roman Kyrylych roman.kyrylych@gmail.com wrote:
2007/9/26, Travis Willard travis@archlinux.org:
On Tue, 25 Sep 2007 14:49:13 -0500 "Aaron Griffin" aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/25/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com 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:
- 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
2007/9/27, Aaron Griffin aaronmgriffin@gmail.com:
Note that we don't need any noarch repo or something like this! We should just do this:
- 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
Am Fri, 28 Sep 2007 11:07:21 +0300 schrieb "Roman Kyrylych" roman.kyrylych@gmail.com:
2007/9/27, Aaron Griffin aaronmgriffin@gmail.com:
Note that we don't need any noarch repo or something like this! We should just do this:
- 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.
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 a.radke@arcor.de wrote:
Am Fri, 28 Sep 2007 11:07:21 +0300 schrieb "Roman Kyrylych" roman.kyrylych@gmail.com:
2007/9/27, Aaron Griffin aaronmgriffin@gmail.com:
Note that we don't need any noarch repo or something like this! We should just do this:
- 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.
Please make sure you don't force us to use the devtools! It should be possible to do the build process without any tools.
Wait wait. This is a totally different issue here.
We should all be using devtools to do this. If you are not for some specific reason, let someone know (we have a bug tracker for a reason).
It is actually important, going forward, that we all use devtools. We all use makepkg right? You're not manually running configure and make, then creating a PKGINFO file. For the same reason we should all ALWAYS use devtools.
Here's a good example. Recently Andy uploaded openoffice, but there was an error during transfer. However, no one noticed and it went into the repos like that. Thomas created a patch that verifies these things when you use devtools.
See, I'm not trying to be an ass by saying "do this", but the simple fact of the matter is that the more unified our process, the less errors we will have.
Andy, can you please inform us as to why you do not use devtools?
On 9/28/07, Andreas Radke a.radke@arcor.de 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.
On 9/28/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
As a different issue here.
This is* a different issue here.
Aaron Griffin wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/25/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 9/25/07, Dan McGee dpmcgee@gmail.com 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
Tuesday 25 September 2007, Dan McGee wrote: | 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...
definitely!
- D
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
Tuesday 25 September 2007, Jürgen Hötzel wrote: | core-noarch | core-i686 | core-x86_64
does this mean, we need to rename the repos to include the ARCH in the name? probably no... but the noarch repo would be only one repo, right? probably with its own categories (fonts, i18n, docs, ...).
a x86_64 archlinux would have then the following repos:
[core] - /core/os/x86_64 [extra] - /extra/os/x86_64 [unstable] - /unstable/os/x86_64
[community] - /community/os/x86_64
[testing] - /testing/os/x86_64
[armarium] - /armarium/os/noarch
armarium would be the new repo, that is arch independend. i took the word from latin for bookcase, since it holds things in it to be read, used but are independend of the reader/user. little bit philosophy... only a suggestion on the name... feel free to take something else if you dislike it.
in such a setup, who would have write access to it? it would be a repo for devs or also TU's? since community is arch dependend!
thinking through the idea, i cannot think of something else more elegant. therefore +1 ... under the condition that we have probably to settle some details on the way of implementing it.
- D
arch-dev-public@lists.archlinux.org