[pacman-dev] pacman packaging
This was just another thought of mine. Pacman is currently distributed as one package on Archlinux (and I would assume on any distribution that is using it). I was thinking it should maybe be two packages, pacman and pacman-utils, or something similar. The two things can be split fairly cleanly- the first is used for installing packages and general maintenence, while the other is used for building packages, looking at the ABS tree, building a custom repo, etc. This also seems more important with a few other scripts being added recently (re-pacman, repo-add) pacman: pacman (and conf/man files), pacman.static, vercmp, rankmirrors, pacman-optimize pacman-utils: abs (and conf files), makepkg (and conf file), makeworld (TODO still wondering if this is used), gensync, resync, repo-add (TODO should this be renamed to addsync?), re-pacman In addition, pacman-utils could then pull in scripts such as srcpac and namcap that are likely installed by most developers anyway. This isn't so much development related, but I thought this was the best list to bring this up. -Dan
I agree and I think it's a good idea, but.. is resync a repair tool for pacman? if so it should be isntalled with pacman, if not, perfect :) On 1/7/07, Dan McGee <dpmcgee@gmail.com> wrote:
This was just another thought of mine. Pacman is currently distributed as one package on Archlinux (and I would assume on any distribution that is using it). I was thinking it should maybe be two packages, pacman and pacman-utils, or something similar. The two things can be split fairly cleanly- the first is used for installing packages and general maintenence, while the other is used for building packages, looking at the ABS tree, building a custom repo, etc. This also seems more important with a few other scripts being added recently (re-pacman, repo-add)
pacman: pacman (and conf/man files), pacman.static, vercmp, rankmirrors, pacman-optimize
pacman-utils: abs (and conf files), makepkg (and conf file), makeworld (TODO still wondering if this is used), gensync, resync, repo-add (TODO should this be renamed to addsync?), re-pacman
In addition, pacman-utils could then pull in scripts such as srcpac and namcap that are likely installed by most developers anyway.
This isn't so much development related, but I thought this was the best list to bring this up.
-Dan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
On Sun, 7 Jan 2007 21:58:46 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
This was just another thought of mine. Pacman is currently distributed as one package on Archlinux (and I would assume on any distribution that is using it). I was thinking it should maybe be two packages, pacman and pacman-utils, or something similar. The two things can be split fairly cleanly- the first is used for installing packages and general maintenence, while the other is used for building packages, looking at the ABS tree, building a custom repo, etc. This also seems more important with a few other scripts being added recently (re-pacman, repo-add)
pacman: pacman (and conf/man files), pacman.static, vercmp, rankmirrors, pacman-optimize
pacman-utils: abs (and conf files), makepkg (and conf file), makeworld (TODO still wondering if this is used), gensync, resync, repo-add (TODO should this be renamed to addsync?), re-pacman
In addition, pacman-utils could then pull in scripts such as srcpac and namcap that are likely installed by most developers anyway.
This isn't so much development related, but I thought this was the best list to bring this up.
-Dan
Not to be contradictory, but what does this gain us? It seperates things, sure, but so what? What problem are we solving by splitting things up? Jason
On 1/8/07, Jason Chu <jason@archlinux.org> wrote:
Not to be contradictory, but what does this gain us? It seperates things, sure, but so what? What problem are we solving by splitting things up?
Part of it was just putting the idea out there and seeing what people thought. However, I think it would follow the KISS policy a bit more, separating package installation from package building. You don't need to install Apache to browse the web (obviously this is not quite that extreme, but helps clarify my point). -Dan
On Mon, 8 Jan 2007 17:51:22 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
On 1/8/07, Jason Chu <jason@archlinux.org> wrote:
Not to be contradictory, but what does this gain us? It seperates things, sure, but so what? What problem are we solving by splitting things up?
Part of it was just putting the idea out there and seeing what people thought. However, I think it would follow the KISS policy a bit more, separating package installation from package building. You don't need to install Apache to browse the web (obviously this is not quite that extreme, but helps clarify my point).
-Dan
I would argue that simple would be not splitting. A second package means more thought: "why can't I build a package? I have pacman installed!"; more maintenance: <aaron>: "Ok, I've got a new version of pacman, now I have to update pacman and pacman-utils". It's true that you don't need to install apache to browse the web, but you do have to install the freeciv server to get the freeciv client, mplayer to get mencoder, sshd to get ssh, and tightvnc to get vncserver. It's usually been our policy not to split if we can help it. Some reasons for splitting are package size (especially when a package is a dependency of another package (see libmysqlclient & postgresql-libs)) or a split upstream. Maybe I'm wrong though. Rpm and dpkg are split in such a way, but they're also huge projects. Jason
I'd have to say that when presented in that manner, I agree that unnesecary splits seem bad. it's a tough issue. on one hand, we could split, but then a user would have to think more. may need a utility and not have it. on the other hand, if we don't split, there are more binaries on a system, and that means more chance for a user to break something. then again, if an arch user breaks something, it's his or her own fault, since we don't claim to be an entry level distro. then again since we're not an entry level distro, we should give a little more thought to security, and system performance, IE not over-crowding the system, etc. there are alot of pros and cons for each way. however, I have to say this: if we split, then aurbuild needs to be included in pacman-utils, or at least in a package (like aur-utils or something) of it's own. On 1/8/07, Jason Chu <jason@archlinux.org> wrote:
On Mon, 8 Jan 2007 17:51:22 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
On 1/8/07, Jason Chu <jason@archlinux.org> wrote:
Not to be contradictory, but what does this gain us? It seperates things, sure, but so what? What problem are we solving by splitting things up?
Part of it was just putting the idea out there and seeing what people thought. However, I think it would follow the KISS policy a bit more, separating package installation from package building. You don't need to install Apache to browse the web (obviously this is not quite that extreme, but helps clarify my point).
-Dan
I would argue that simple would be not splitting. A second package means more thought: "why can't I build a package? I have pacman installed!"; more maintenance: <aaron>: "Ok, I've got a new version of pacman, now I have to update pacman and pacman-utils".
It's true that you don't need to install apache to browse the web, but you do have to install the freeciv server to get the freeciv client, mplayer to get mencoder, sshd to get ssh, and tightvnc to get vncserver.
It's usually been our policy not to split if we can help it. Some reasons for splitting are package size (especially when a package is a dependency of another package (see libmysqlclient & postgresql-libs)) or a split upstream.
Maybe I'm wrong though. Rpm and dpkg are split in such a way, but they're also huge projects.
Jason
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
2007/1/9, Christ Schlacta <aarcane@gmail.com>:
I'd have to say that when presented in that manner, I agree that unnesecary splits seem bad.
it's a tough issue. on one hand, we could split, but then a user would have to think more. may need a utility and not have it.
on the other hand, if we don't split, there are more binaries on a system, and that means more chance for a user to break something.
then again, if an arch user breaks something, it's his or her own fault, since we don't claim to be an entry level distro.
then again since we're not an entry level distro, we should give a little more thought to security, and system performance, IE not over-crowding the system, etc.
there are alot of pros and cons for each way. however, I have to say this: if we split, then aurbuild needs to be included in pacman-utils, or at least in a package (like aur-utils or something) of it's own.
I was thinking about pacman split for a long time, but my point is a bit different. I think split should be done at the same time with gcc->libgcc move. Most packages doesn't need full gcc to run. Splitting making all those packages to depend on libgcc (or remove glibc and gcc deps at all as they are in base install anyway) will allow to have more clean system for those who doesn't ever compile anything. No automake/autoconf/etc. Then only pacman-utils (makepkg, abs, versionpkg, srcpac etc.) should depend on full gcc, while pacman will not require it, of course. That's how I see this. About aurbuild and other AUR tools - they should not be part of pacman-utils because they may and will change independently of other pacman utils as they depend on AUR changes. -- Roman Kyrylych (Роман Кирилич)
good point, but then I think there needs to be an aur-utils package, even if it's left in testing or some other infrequently used repo. On 1/9/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/1/9, Christ Schlacta <aarcane@gmail.com>:
I'd have to say that when presented in that manner, I agree that unnesecary splits seem bad.
it's a tough issue. on one hand, we could split, but then a user would have to think more. may need a utility and not have it.
on the other hand, if we don't split, there are more binaries on a system, and that means more chance for a user to break something.
then again, if an arch user breaks something, it's his or her own fault, since we don't claim to be an entry level distro.
then again since we're not an entry level distro, we should give a little more thought to security, and system performance, IE not over-crowding the system, etc.
there are alot of pros and cons for each way. however, I have to say this: if we split, then aurbuild needs to be included in pacman-utils, or at least in a package (like aur-utils or something) of it's own.
I was thinking about pacman split for a long time, but my point is a bit different. I think split should be done at the same time with gcc->libgcc move. Most packages doesn't need full gcc to run. Splitting making all those packages to depend on libgcc (or remove glibc and gcc deps at all as they are in base install anyway) will allow to have more clean system for those who doesn't ever compile anything. No automake/autoconf/etc. Then only pacman-utils (makepkg, abs, versionpkg, srcpac etc.) should depend on full gcc, while pacman will not require it, of course. That's how I see this.
About aurbuild and other AUR tools - they should not be part of pacman-utils because they may and will change independently of other pacman utils as they depend on AUR changes.
-- Roman Kyrylych (Роман Кирилич) _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
participants (4)
-
Christ Schlacta
-
Dan McGee
-
Jason Chu
-
Roman Kyrylych