[pacman-dev] [PATCH] New --nonew option
See the attachment for patch. Other recommendations for option name and English language fixes are welcome :-P ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
I fixed some bugs. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Fri, Feb 29, 2008 at 02:11:11PM +0100, Nagy Gabor wrote:
This is the next member of our target-list filter options (--needed, --unneeded). With this option pacman won't add new packages (which cannot be found in localdb), only upgrade/reinstall old ones. This implement the request of FS#8137. See also: http://www.archlinux.org/pipermail/pacman-dev/2007-October/009650.html I also added sync022.py to test the new option. Note: I rephrased the descriptions of --needed to emphasize that it is a filter option (--nonew is usually used with --needed). Note: in the future we can implement a new --freshen option == --needed + --nonew.
+*\--nonew*:: + Pacman won't install new (not-yet-installed) packages, except if they are + needed by others (as dependency). This is mostly used in group + operations to restrict pacman to installed packages of the group. + For example 'pacman -S base --nonew --needed' will upgrade your + base group, but won't add new packages from base. +
Should we really support upgrading a particular set of packages (as opposed to the whole system with -Su) by adding features to ease up that task?
On Sat, Mar 01, 2008 at 09:03:39PM +0100, Xavier <shiningxc@gmail.com> wrote:
Should we really support upgrading a particular set of packages (as opposed to the whole system with -Su) by adding features to ease up that task?
this sounds quite Debianish, where you need dist-upgrade for -Su.. (IMHO horrible, but it's not my task to reject patches :) ) - VMiklos
Xavier wrote:
On Fri, Feb 29, 2008 at 02:11:11PM +0100, Nagy Gabor wrote:
+*\--nonew*:: + Pacman won't install new (not-yet-installed) packages, except if they are + needed by others (as dependency). This is mostly used in group + operations to restrict pacman to installed packages of the group. + For example 'pacman -S base --nonew --needed' will upgrade your + base group, but won't add new packages from base. +
Should we really support upgrading a particular set of packages (as opposed to the whole system with -Su) by adding features to ease up that task?
The example "pacman -S base --nonew --needed" command seemed a great way for people to break their system to me. If there are a lot of rebuilds with a major package update (e.g. perl, db, kernel26...) then it would be possible to run into trouble. Also, I don't know of any distro that officially supports systems that are not fully updated. Allan
The example "pacman -S base --nonew --needed" command seemed a great way for people to break their system to me. If there are a lot of rebuilds with a major package update (e.g. perl, db, kernel26...) then it would be possible to run into trouble.
Also, I don't know of any distro that officially supports systems that are not fully updated.
Allan
I agree, that the command line is ugly, but 1. pacman is not distro specific 2. Archlinux has "rolling fashion" package upgrades; where pacman -S "pkg1 pkg2 pkg3 ... pkgn" is supported; thus dependencies should be filled in properly 3. The ugly command will prevent using it "accidentally" 4. This was a FR. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Mon, Mar 03, 2008 at 01:13:45PM +1000, Allan McRae <mcrae_allan@hotmail.com> wrote:
Also, I don't know of any distro that officially supports systems that are not fully updated.
wrong, Debian, Gentoo, Frugalware does for sure (and probably others as well).
Miklos Vajna wrote:
On Mon, Mar 03, 2008 at 01:13:45PM +1000, Allan McRae <mcrae_allan@hotmail.com> wrote:
Also, I don't know of any distro that officially supports systems that are not fully updated.
wrong, Debian, Gentoo, Frugalware does for sure (and probably others as well).
So, if I want to use binutils 2.18 with glibc 2.4 then these are the distributions to use... To clarify, I meant that no distribution will support partially updated systems, in that if the current version of "package 1" does not work with an old version of "package 2" but it does with the latest version, the solution to a bug report won't be update your system. As I outlined in the original email, I could see many package incompatibilities like this happening if pacman could upgrade part of the system. That is why I don't like the example command given for the --nonew option.
So, if I want to use binutils 2.18 with glibc 2.4 then these are the distributions to use... To clarify, I meant that no distribution will support partially updated systems, in that if the current version of "package 1" does not work with an old version of "package 2" but it does with the latest version, the solution to a bug report won't be update your system. As I outlined in the original email, I could see many package incompatibilities like this happening if pacman could upgrade part of the system. That is why I don't like the example command given for the --nonew option.
OK, in the example consider xmms-plugins group. I think 100% acceptable if you want to upgrade your packages belong to xmms-plugins group (after xmms upgrade) without upgrading firefox, openoffice etc. On the other hand, if "package 1" doesn't work with "package 2", then this should be handled by dependencies (package_1 depends on package_2>=3.0) or conflicts, since pacman -S "package 1" is also allowed (-S --nonew --needed is just makes a certain type of package selection easier). Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Wed, Mar 05, 2008 at 10:43:34AM +0100, Nagy Gabor wrote:
OK, in the example consider xmms-plugins group. I think 100% acceptable if you want to upgrade your packages belong to xmms-plugins group (after xmms upgrade) without upgrading firefox, openoffice etc. On the other hand, if "package 1" doesn't work with "package 2", then this should be handled by dependencies (package_1 depends on package_2>=3.0) or conflicts, since pacman -S "package 1" is also allowed (-S --nonew --needed is just makes a certain type of package selection easier).
If you are just using a few packages from a group, can't you just install these packages manually? Or if you use many packages from a group, can't you just put the remaining ones to IgnorePkg?
2008/3/5, Nagy Gabor <ngaba@bibl.u-szeged.hu>:
So, if I want to use binutils 2.18 with glibc 2.4 then these are the distributions to use... To clarify, I meant that no distribution will support partially updated systems, in that if the current version of "package 1" does not work with an old version of "package 2" but it does with the latest version, the solution to a bug report won't be update your system. As I outlined in the original email, I could see many package incompatibilities like this happening if pacman could upgrade part of the system. That is why I don't like the example command given for the --nonew option.
OK, in the example consider xmms-plugins group. I think 100% acceptable if you want to upgrade your packages belong to xmms-plugins group (after xmms upgrade) without upgrading firefox, openoffice etc. On the other hand, if "package 1" doesn't work with "package 2", then this should be handled by dependencies (package_1 depends on package_2>=3.0) or conflicts, since pacman -S "package 1" is also allowed (-S --nonew --needed is just makes a certain type of package selection easier).
heh, so many-many gtk2-dependant packages should have depends=('gtk2>=2..4/2.6/2.8/210/whatever') this is just unreal, nobody will want to check that stuff (because it's not trivial and consumes valuable time) P.S.: this comment is just about "this should be handled by dependencies", not about the --nonew. -- Roman Kyrylych (Роман Кирилич)
heh, so many-many gtk2-dependant packages should have depends=('gtk2>=2..4/2.6/2.8/210/whatever') this is just unreal, nobody will want to check that stuff (because it's not trivial and consumes valuable time)
1. A bit off-topic, about packaging: * Well, obviously nobody wants to recheck existing packages... Hopefully your distro's packaging policy declares that dependencies should be filled in correctly. * If I cannot assume this, then what can I expect from the packager? Almost all projects have an INSTALL file or something which defines clearly the minimal version of its dependencies (or can be caught easily from configure.ac). * To be more concrete: with ArchLinux I had only about 3 missing depver issues for ~5 years, after reporting them, they were fixed soon. 2. Summarize my opinion: if user can select any set of packages for upgrade (see also: upcoming GUIs), I don't see why they are forced to do some shell magic to do what they want. ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
2008/3/7 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
heh, so many-many gtk2-dependant packages should have depends=('gtk2>=2..4/2.6/2.8/210/whatever') this is just unreal, nobody will want to check that stuff (because it's not trivial and consumes valuable time)
1. A bit off-topic, about packaging: * Well, obviously nobody wants to recheck existing packages... Hopefully your distro's packaging policy declares that dependencies should be filled in correctly. * If I cannot assume this, then what can I expect from the packager? Almost all projects have an INSTALL file or something which defines clearly the minimal version of its dependencies (or can be caught easily from configure.ac). * To be more concrete: with ArchLinux I had only about 3 missing depver issues for ~5 years, after reporting them, they were fixed soon.
Well, did you try to break it, or did you more or less do normal upgrades? If you are not trying to do anything stupid, it will probably work well. But if you are trying every possible combinations of different package versions, you will probably find much more problems.
2. Summarize my opinion: if user can select any set of packages for upgrade (see also: upcoming GUIs), I don't see why they are forced to do some shell magic to do what they want.
Users can select any set of packages to install. Otherwise, that would be a rather odd package manager. But it just turns out that installing a version of package from a repo when you already have an older package == upgrading.
2008/3/7 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
heh, so many-many gtk2-dependant packages should have depends=('gtk2>=2..4/2.6/2.8/210/whatever') this is just unreal, nobody will want to check that stuff (because it's not trivial and consumes valuable time)
1. A bit off-topic, about packaging: * Well, obviously nobody wants to recheck existing packages... Hopefully your distro's packaging policy declares that dependencies should be filled in correctly. * If I cannot assume this, then what can I expect from the packager? Almost all projects have an INSTALL file or something which defines clearly the minimal version of its dependencies (or can be caught easily from configure.ac). * To be more concrete: with ArchLinux I had only about 3 missing depver issues for ~5 years, after reporting them, they were fixed soon.
Well, did you try to break it, or did you more or less do normal upgrades? If you are not trying to do anything stupid, it will probably work well. But if you are trying every possible combinations of different package versions, you will probably find much more problems.
Of course I didn't try to break it, but I used -S many times to upgrade packages. I still don't understand why I should upgrade openoffice (I'm not an ooo user;-), if I want to upgrade audacious. ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
2008/3/7 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
Of course I didn't try to break it, but I used -S many times to upgrade packages. I still don't understand why I should upgrade openoffice (I'm not an ooo user;-), if I want to upgrade audacious.
Because it's so much simpler to update the damn whole system rather than wondering whether a partial update will work or not. Doesn't that make any sense? Of course, there are many cases where you can do it, and it will not break. But there are also cases where it will break, which is why I was just thinking that maybe we should not add any features that encourage doing partial updates, or at least make it easier.
On Fri, Mar 07, 2008 at 12:57:48PM +0100, Xavier <shiningxc@gmail.com> wrote:
Because it's so much simpler to update the damn whole system rather than wondering whether a partial update will work or not. Doesn't that make any sense?
practically - yes. as you have to use -Syu to keep your system secure. technically, dependencies could handle the case when the user avoids -Syu for a long time.
2008/3/7 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
Of course I didn't try to break it, but I used -S many times to upgrade packages. I still don't understand why I should upgrade openoffice (I'm not an ooo user;-), if I want to upgrade audacious.
Because it's so much simpler to update the damn whole system rather than wondering whether a partial update will work or not. Doesn't that make any sense?
Of course, there are many cases where you can do it, and it will not break. But there are also cases where it will break, which is why I was just thinking that maybe we should not add any features that encourage doing partial updates, or at least make it easier.
OK. I've never heart complaints against -Rd and -Sd; they are the real database and system breakers. But they are optional, nobody said, that you must use any of them. The same for --nonew. And using it is _my_ responsibility, not the package manager's. [Btw, my philosophy: If I'm not allowed to break my system, then my freedom is restricted (or I am treated like a child);-)] This was a FR, and personally I find it also useful. I don't see why this is so dangerous (I mean it worth not to suffice some needs, while there are no regressions to others). [Btw, I think this patch ugly because of patching back-end instead of the front-end, not because of its philosophy]. I don't think, anyone can convince me about the (assumed) fact that this feature is bad, so I let the decision to Dan (as always). Technical discussion are welcome of course. Bye
On Fri, Mar 07, 2008 at 08:20:58PM +0100, Nagy Gabor wrote:
OK. I've never heart complaints against -Rd and -Sd; they are the real database and system breakers. But they are optional, nobody said, that you must use any of them. The same for --nonew. And using it is _my_ responsibility, not the package manager's. [Btw, my philosophy: If I'm not allowed to break my system, then my freedom is restricted (or I am treated like a child);-)] This was a FR, and personally I find it also useful. I don't see why this is so dangerous (I mean it worth not to suffice some needs, while there are no regressions to others). [Btw, I think this patch ugly because of patching back-end instead of the front-end, not because of its philosophy]. I don't think, anyone can convince me about the (assumed) fact that this feature is bad, so I let the decision to Dan (as always). Technical discussion are welcome of course.
Well personally, I don't like Rd and Sd :) But you have a valid point, and that's also why I was never 100 % against your patch (even if I maybe made it sound like it :)). If we want to give more power to users, and then its their jobs to not do stupid things with it, then your patch is perfectly fine.
OK. I've never heart complaints against -Rd and -Sd; they are the real database and system breakers. But they are optional, nobody said, that you must use any of them. The same for --nonew. And using it is _my_ responsibility, not the package manager's. [Btw, my philosophy: If I'm not allowed to break my system, then my freedom is restricted (or I am treated like a child);-)] This was a FR, and personally I find it also useful. I don't see why this is so dangerous (I mean it worth not to suffice some needs, while there are no regressions to others). [Btw, I think this patch ugly because of patching back-end instead of the front-end, not because of its philosophy]. I don't think, anyone can convince me about the (assumed) fact that this feature is bad, so I let the decision to Dan (as always). Technical discussion are welcome of course.
Well personally, I don't like Rd and Sd :) But you have a valid point, and that's also why I was never 100 % against your patch (even if I maybe made it sound like it :)). If we want to give more power to users, and then its their jobs to not do stupid things with it, then your patch is perfectly fine.
Good. Now let's the technical discussion come;-) To be honest, I don't really like the way this patch works. I did this, because this was the easier (and I'm lazy ;-) and I followed the --needed option way. But in both cases the target filtering can be done in the front-end (and this would be nicer imho). However, this would be a bit duplicated work (and not notable slow-down), if we scanned for local version(number) in the front-end too. And it is a bit strange, that we pull a package with addtarget, and some targets are silently filtered out... In both cases only addtarget are affected. So the question is: shouldn't we move some options to front-end? Contras: -possible duplication in multiple front-ends -config->flags |= PM_TRANS_FLAG_NEEDED schema is the easiest we can imagine, thus put all work to the back-end Pros: -imho these stuffs fit clearly in front-end -we should(?) fit in 32 bits of flags ;-) IMHO the main reason that these hurt my taste ;-) In the two mentioned option (--needed and possible --nonew <- terrible name), we could also add a filter option (flag?!;-) to addtarget only, because these are not transaction level stuffs, just "addtarget filters". Bye
On Fri, Mar 07, 2008 at 08:57:55PM +0100, Nagy Gabor wrote:
Good. Now let's the technical discussion come;-) To be honest, I don't really like the way this patch works. I did this, because this was the easier (and I'm lazy ;-) and I followed the --needed option way. But in both cases the target filtering can be done in the front-end (and this would be nicer imho). However, this would be a bit duplicated work (and not notable slow-down), if we scanned for local version(number) in the front-end too. And it is a bit strange, that we pull a package with addtarget, and some targets are silently filtered out... In both cases only addtarget are affected. So the question is: shouldn't we move some options to front-end? Contras: -possible duplication in multiple front-ends -config->flags |= PM_TRANS_FLAG_NEEDED schema is the easiest we can imagine, thus put all work to the back-end Pros: -imho these stuffs fit clearly in front-end -we should(?) fit in 32 bits of flags ;-)
IMHO the main reason that these hurt my taste ;-) In the two mentioned option (--needed and possible --nonew <- terrible name), we could also add a filter option (flag?!;-) to addtarget only, because these are not transaction level stuffs, just "addtarget filters".
You might be right, using trans flags everywhere might not be a good idea. I am not sure how nice it will be to implement in the frontend though.
On Fri, Mar 7, 2008 at 2:34 PM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Mar 07, 2008 at 08:20:58PM +0100, Nagy Gabor wrote:
OK. I've never heart complaints against -Rd and -Sd; they are the real database and system breakers. But they are optional, nobody said, that you must use any of them. The same for --nonew. And using it is _my_ responsibility, not the package manager's. [Btw, my philosophy: If I'm not allowed to break my system, then my freedom is restricted (or I am treated like a child);-)] This was a FR, and personally I find it also useful. I don't see why this is so dangerous (I mean it worth not to suffice some needs, while there are no regressions to others). [Btw, I think this patch ugly because of patching back-end instead of the front-end, not because of its philosophy]. I don't think, anyone can convince me about the (assumed) fact that this feature is bad, so I let the decision to Dan (as always). Technical discussion are welcome of course.
Well personally, I don't like Rd and Sd :) But you have a valid point, and that's also why I was never 100 % against your patch (even if I maybe made it sound like it :)). If we want to give more power to users, and then its their jobs to not do stupid things with it, then your patch is perfectly fine.
After thinking about this patch, I guess I have to give it a -1. Why? First, I'm just not sold that we need this type of behavior in libalpm. Like you said, this seems like something we should do in a frontend. It makes much more sense to me for a GUI tool to offer selections like this, but for a command line tool, I think we could script this behavior rather than modify the source. Second, I just have to draw the line somewhere with regards to new options and flags, and I just don't like this one enough to want to include it and have to support it into the future. Keep up the creative thought though- I'm glad to see we could do things like this if we wanted to. Perhaps we should ask- what would we need to do to libalpm to be able to easily do things like this from a frontend instead? -Dan
On Mon, Mar 10, 2008 at 07:33:39PM -0500, Dan McGee wrote:
After thinking about this patch, I guess I have to give it a -1. Why?
First, I'm just not sold that we need this type of behavior in libalpm. Like you said, this seems like something we should do in a frontend. It makes much more sense to me for a GUI tool to offer selections like this, but for a command line tool, I think we could script this behavior rather than modify the source.
Second, I just have to draw the line somewhere with regards to new options and flags, and I just don't like this one enough to want to include it and have to support it into the future.
Keep up the creative thought though- I'm glad to see we could do things like this if we wanted to. Perhaps we should ask- what would we need to do to libalpm to be able to easily do things like this from a frontend instead?
That makes sense indeed.
participants (6)
-
Allan McRae
-
Dan McGee
-
Miklos Vajna
-
Nagy Gabor
-
Roman Kyrylych
-
Xavier