Bug#597221: (no subject)
What do you expect instead? For me this is a not easy to solve situation. Both actions can be interpreted as the desired, but software can't decide this on the information you've specified. An additional problem is, that install_packages does not take the order of classes into account, which worked so far for everybody. -- regards Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597221: (no subject)
> What do you expect instead? > > For me this is a not easy to solve situation. Both actions can be > interpreted as the desired, but software can't decide this on the > information you've specified. > An additional problem is, that install_packages does not take the > order of classes into account, which worked so far for everybody. Well, and what if the same class listed the package both as remove and install? I completely agree with Thomas that it should not be install_packages' task to be cleverer than the user. What could be nice to have, however, is a warning. Thomas, would that be feasible? I quickly looked over the code yesterday, but got a bit lost, didn't really know where to start... Best, Michael pgp1sHni90ILJ.pgp Description: PGP signature
Bug#597221: (no subject)
> What do you expect instead? > > For me this is a not easy to solve situation. Both actions can be > interpreted as the desired, but software can't decide this on the > information you've specified. > An additional problem is, that install_packages does not take the > order of classes into account, which worked so far for everybody. Well, and what if the same class listed the package both as remove and install? I completely agree with Thomas that it should not be install_packages' task to be cleverer than the user. What could be nice to have, however, is a warning. Thomas, would that be feasible? I quickly looked over the code yesterday, but got a bit lost, didn't really know where to start... Best, Michael (resending, fixed -submitter address) pgpTbojKJk3as.pgp Description: PGP signature
Bug#597221: (no subject)
> On Sat, 18 Sep 2010 14:31:59 +0200, Michael Tautschnig > said: > be cleverer than the user. What could be nice to have, however, > is a warning. IMO it's not worth the work. Since install_packages is very stupid about the packages lists it collects and the just append to the install or remove command, I guess it's more work to implement it. And it makes install_packages much more complicated, what I do not like to do. -- regards Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597221: (no subject)
Hi, (no need to cc: my, I'm still subscribed to the PTS :) On Samstag, 18. September 2010, Thomas Lange wrote: > What do you expect instead? That the package is removed. The logic being: as "install" is the default action, "remove" should have a higher "priority" and be whats happens. > For me this is a not easy to solve situation. Both actions can be > interpreted as the desired, but software can't decide this on the > information you've specified. > An additional problem is, that install_packages does not take the > order of classes into account, which worked so far for everybody. That would still not be needed. Just "if a package is both listed to be installed and removed, remove it". The reason is that I have quite a few classes which have some exceptions, like a class REALHW for systems running on real hardware. Usually those systems needs smartmontools, but some don't as they dont have discs. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#597221: (no subject)
> Hi, > > (no need to cc: my, I'm still subscribed to the PTS :) > > On Samstag, 18. September 2010, Thomas Lange wrote: > > What do you expect instead? > > That the package is removed. > > The logic being: as "install" is the default action, "remove" should have a > higher "priority" and be whats happens. > > > For me this is a not easy to solve situation. Both actions can be > > interpreted as the desired, but software can't decide this on the > > information you've specified. > > An additional problem is, that install_packages does not take the > > order of classes into account, which worked so far for everybody. > > That would still not be needed. Just "if a package is both listed to be > installed and removed, remove it". > > The reason is that I have quite a few classes which have some exceptions, > like > a class REALHW for systems running on real hardware. Usually those systems > needs smartmontools, but some don't as they dont have discs. > I do have such situations as well, and do resolve them as follows: otherclass: PACKAGES install smartmontools REALHW PACKAGES install smartmontools- That seems to work fine, i.e., X- dominates X, although I couldn't really figure out from the code of install_packages why this works the way it does :-) But if I remember it correctly, that was implemented around the first FAI workshop (and it is a very useful feature indeed :-) - hmm, does that contradict my previous post?). Best, Michael pgpH5ruCFqf6g.pgp Description: PGP signature
Bug#597221: (no subject)
Hi, On Sonntag, 19. September 2010, Michael Tautschnig wrote: > I do have such situations as well, and do resolve them as follows: > > otherclass: > PACKAGES install > smartmontools > > > REALHW > PACKAGES install > smartmontools- Did you mean: otherclass: PACKAGES install smartmontools- REALHW PACKAGES install smartmontools ? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#597221: (no subject)
> Hi, > > On Sonntag, 19. September 2010, Michael Tautschnig wrote: > > I do have such situations as well, and do resolve them as follows: > > > > otherclass: > > PACKAGES install > > smartmontools > > > > > > REALHW > > PACKAGES install > > smartmontools- > > Did you mean: > > otherclass: > PACKAGES install > smartmontools- > > > REALHW > PACKAGES install > smartmontools > > ? > Err, yes, right. Sorry, Michael pgpfhizARq7qg.pgp Description: PGP signature
Bug#597221: (no subject)
retitle 597221 please include examples for howto remove some packages from a CLASS for another class severity 597221 wishlist thanks Hi, On Sonntag, 19. September 2010, Michael Tautschnig wrote: > Err, yes, right. > Sorry, no problem, I'm rather happy you pointed this out here. Maybe this should be spelled out in the documentation? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#597221: (no subject)
I think we can close this bug, since a solution is described. -- regards Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
