Blacklist for Updates?

[Richard_Walker]

Here's a thought. Why don't we have a way to "permanently" blacklist an update as well as having the temporary checkbox on the updates screen to de-select it for now?

It isn't hard to guess why nobody thought of this before; after all, we couldn't imagine why someone would want to apply some updates and not others. Furthermore, partially updated systems are almost as insecure as completely unpatched ones. The flaw in this logic is that not all updates are security/bug-fix updates. Some are backports and some introduce new bugs.

I would like to see a mechanism in the update module which would allow you to de-select the updates which are not wanted, complete the update process and then select from the remaining (previously de-selected updates) which ones should be added to a blacklist file so that they will not again be offered for updating.

The advantage of this approach is that an update which breaks something can be completely quarantined and kept away from unsuspecting users. For an example, consider a number of PCs running 2008.1 with the automatic updating helper running.

Each PC is used by a child to run gcompris v8.4.4. The children do not have access to a root account and the systems are maintained by a responsible person who will not always be present while the computers are in use. Shortly after logon, a child can expect to be presented with the "updates are available" prompt. They have been educated to understand the necessity of keeping their systems up to date and can be expected to apply the advertised updates.

The responsible person has determined that the v8.4.5 update breaks, so it has been removed and all machines reverted to 8.4.4. Thanks to the user accessible, and otherwise valuable update helper, each machine remains vulnerable to an accidental update until 8.4.6 comes along.

Other scenarios are pssible and need not involve avoiding a broken update.

Would anyone else like to be able to blacklist an update?

Richard

[rolfp]

[Richard_Walker]

Wow Rolf, I have been using Linux since Madrake 7.2 and I am still being surprised by useful features I didn't know were there. I thought I was getting all the info I needed when I read the Mandriva manual on managing software installation and updates a couple of days ago.

So, half the work at least is already done. This is indeed the blacklist I was thinking of. Now all we need, I think, is a way to get it into use by everyone who needs it. I don't suppose it would be too hard to add some code to rpmdrake (I imagine that is where this is handled) to manage additions to and deletions from this list.

[awilliamson]

No, we won't do that. There's a general model on MDV that particularly MandrivaUpdate and to a certain extent rpmdrake are kept relatively simple in terms of interface and functionality, and advanced functions are reserved to urpmi / manual config file changes. It's been discussed before, and we don't want to include skip.list management in the rpmdrake or MandrivaUpdate interfaces. Sorry.
_________________
Adam Williamson | http://www.happyassassin.net
Fedora QA community monkey
Mandriva contributor, former community manager

[Richard_Walker]

I'm sorry I missed the discussion, but we have what we have. From Rolf's info and my own experiments I can see that the skip list will let me do what I need and I am sure I can find a way to let an unprivileged user update the list when necessary.

One other suggestion comes to mind though. Perhaps this isn't the right place to bring it up. The skip list would be a lot more useful (and I would have found out about it sooner) if it were documented in the manual section which deals with updating software. It also needs an explanation of the format of an entry as examples I have seen use the / character for some purpose and none of the examples indicates how to include the version part of a package name.

[teknokraft]

Again, if a new user were to see that, and go in a-blacklisting away, they could blacklist their way into hosing their system.

We're not out for that aim, sorry.

The skip.list should only be used by those who know what they're doing, and only for specific reasons; i.e. if a specific update would mess up their system somehow or something like that (i.e. if through troubleshooting, it's found a specific update ruins or "messes up" a system in some way, and the person is literally told to blacklist that specific update).

It's not for just anyone to go there into, and start blacklisting to their heart's content for.

[Richard_Walker]

I am sorry I cannot agree with your sentiment. I don't see how keeping information from people can be condoned in an open environment like ours. Perhaps it works well for users of proprietary products.

I see a distinction between a hosed system that has come about due to an over-hasty (and blindly trusted) update and one which results from an update not being applied. In the first case one is not likely to have an idea what went wrong. In the other, a decision was made, for whatever reason, to avoid an update. The reason for that decision is likely to be taken into account when assessing why a system is now "hosed".

I have to wonder how many people, like me, could have benefitted from knowing about the skip list, and how to use it properly. Surely this is the best contradiction of your position. If the list and its use were properly documented then your postulated unworthy would be properly educated and more likely to use the facility in the right way and for the right reasons.

[David Batson]

[EmmetCurran]

[jkerr82508]

See man urpmi.files

Jim

[awilliamson]

emmet: we don't actually recommend having /backports set up as an 'update' repository...

and no, you couldn't really break your system with skip.list . well there's probably some odd way to do it, but it'd take ingenuity. That's not the reason we don't have it in the GUI. The reason is simply, as I've written in other threads, that we have a policy of keeping rpmdrake a very simple app which lets you do basic package management functions, rather than a do-it-all app with seventy buttons and thirty menus. We prefer to keep advanced features in the CLI simply to keep rpmdrake clean and easy to use for the most commonly used procedures.
_________________
Adam Williamson | http://www.happyassassin.net
Fedora QA community monkey
Mandriva contributor, former community manager

[EmmetCurran]

[awilliamson]

The recommended way to use /backports is to enable it when you want to install something specific from it, and then disable it again afterwards. Or at most, have it enabled so you can search for packages in it and so on, but don't have it set as an update source.
_________________
Adam Williamson | http://www.happyassassin.net
Fedora QA community monkey
Mandriva contributor, former community manager

[EmmetCurran]

so if you want to update something you downloaded from /backports you should uninstall it first, yes? or will the update be available as a new download alongside the installed version?

thanks

[Ahmad_Samir]

Technically speaking when you update a package that you have installed with a package from backports or what ever repositories it does an upgrade. Upgrade=uninstall old package then install new package. I might be wrong of course.

[EmmetCurran]

i was just wondering in terms of it being available. if i were to download a program, say v1.00, and then v1.01 is released as an update it won't show up in my 'updates available' thingy.
i'm guessing it won't show up as a new program if searched for in the repo until v1.00 is removed first? or will it show side-by-side as two versions of the program?
i think i've seen both these instances but am not sure when or, more importantly, why.

thanks

[Ahmad_Samir]

Oh, so that's what you mean. Yes both old and new packages will show in rpmdrake. But of course if the newer package is in backports and you have disabled backports then you *shouldn't* be able to see it in rpmdrake. What happens is that due to a bug (I think) in rpmdrake it still shows some newer packages from backports even if you have disabled it.

[jkerr82508]

Only bug fixes and security fixes are displayed as Updates. New versions of applications are generally made available only when Mandriva issues a new release (such as Mandriva 2009.0).

Sometimes new versions of applications are made available as backports. When this happens the new version and the previous version will both be found when you search in the Software Manager.

Jim

[awilliamson]

If you enable the backports repository, you'll see the new version in rpmdrake. You don't have to remove the old one first.
_________________
Adam Williamson | http://www.happyassassin.net
Fedora QA community monkey
Mandriva contributor, former community manager

[aapgorilla]

[dsmithhfx]

Here are a few examples of stuff I don't want updated, or to ever appear in the list of updates. I wish it were easier to exclude them, and to know that they can in fact be excluded (well, now I do -- no thanks to 'official' policy):

spellcheckers for every language known to man. I will only ever use my native language on my installation of Mandriva and, god-willing, no one else will ever have access to my installation of Mandriva. So I don't need them or want them. Clear on that?

Open office. I uninstalled it, and installed koffice. I don't want open office, Period. I don't want open office "updates", Period (er -- how do you "update" something that is no longer present on your system, anyway?).

Nvidia drivers. I don't have an Nvidia card. I don't anticipate needing one anytime soon. When and if I do, I will install Nvidia drivers. Not before. Thanks, anyway.

There's a bunch of stuff that is blindly installed by default for hardware that is not even present, and features I don't need or want. This wastes installation time, and time downloading and updating stuff I don't need or want.

Surely that's a bad thing?

[David Batson]

[awilliamson]

Right. The updater only offers updates for installed packages, it does not add packages (except in the case where, at release time, A required only B, but the updated version of A requires both B and C, then the updater will obviously add C). If there are packages installed on your system which you don't need, you can easily remove them from the package management tool, and then the updater will not offer you updates for them.

In 2009, One will strip unnecessary packages from the system following installation, so installing from 2009 One won't leave you with as many extraneous packages as it did in 2008 Spring and earlier.
_________________
Adam Williamson | http://www.happyassassin.net
Fedora QA community monkey
Mandriva contributor, former community manager

[dsmithhfx]

Well, I'm puzzled by that because I did a complete uninstall of openoffice using the package manager, that is, I unchecked everything with openoffice (or suchlike) in its name, clicked apply, and watched the progress bar as it deleted those files (openoffice is not in the applications menu no more). So now, every time I look at auto update, there is the openoffice base wotsit wanting to get back in.

The stuff about stripping uneccessary packages in the next release is great news (in fact I just dl rc1 to have a look at how that is coming along).

The point of my earlier post is that, just maybe, an easier means of blacklisting unwanted updates could be a good thing from a usability perspective. A number of other distros support this feature, usually by right-clicking on the package for a contextual menu.

I mean, if you don't want new users messing about with Mandriva's guts and configuratin' stuff, then you better hide the CLI. And the manual. Oh, and disable Google while you're at it.

[::: MaraST78 :::]