I don't know whether to blame pacman or a package

laddiebuck · 2005-08-31 00:19:14

But this is totally messed up. I just uninstalled initscripts-gensplash. Guess what happens? I find both /etc/rc.sysinit and /etc/rc.conf deleted, gone. Also /etc/inittab, but fortunately that was just moved to .pacsave. If I had not noticed all this, I would now have a pretty unbootable system. I don't know whether to fault pacman, which blindly and happily deleted those files without saving them, confirming their deletion, or anything, or to fault the initscripts-gensplash package, which happily overwrote those files and decided they had to be deleted at uninstall time.

jftaylor21 · 2005-08-31 01:14:15

I'm sorry to hear this happened. I think that dibblethewrecker maintains that package so it might be best to contact him about it. If you want thoses files back, you will need to reinstall initscripts again.

deficite · 2005-08-31 01:54:04

The problem is that initscripts-gensplash replaces the package "initscripts" which provides your /etc/ files for starting up your computer. You need to reinstall the plain "initscripts" package or copy your "pacsave" files that might still be in your /etc/ directory back to their appropriate names.

cactus · 2005-08-31 01:58:17

or put those files in /etc/pacman.conf, as NoUpgrade.

laddiebuck · 2005-08-31 03:04:21

I had actually specified /etc/rc.sysinit as a NoUpgrade in pacman.conf. What worries me most is that rc.conf was blithely wiped.

laddiebuck · 2005-08-31 04:13:13

Also, I know this is a religious thing, but... with SysV style initscripts the likelihood of this happening would have been much slimmer.

sepht · 2005-08-31 05:54:36

laddiebuck wrote:

Also, I know this is a religious thing, but... with SysV style initscripts the likelihood of this happening would have been much slimmer.

yeh, but who in the world would want to drop the entire BSD-style init which is a strong reason many people like arch, just to help prevent an odd mishap with a package.

My only issue is that it touchs the config file, the package seems to be including an rc.conf.. yet I don't see why it should, there's no evident difference between the one in the CVS and the default one(unless I missed something)

as for the rest of the initscripts:
Removing a set of initscripts without installing a replacement pair seems like a user-side issue though; :oops: :?

dtw · 2005-08-31 08:12:00

sepht wrote:

My only issue is that it touchs the config file, the package seems to be including an rc.conf.. yet I don't see why it should, there's no evident difference between the one in the CVS and the default one(unless I missed something)

Hmmmm, so I guess you think there is some magical way that pacman can only uninstall half a pkg before installing a new pkg over the top?

There is supposed to be a warning when you remove initscripts-gensplash to remind you to install another initscripts pkg, but it seems it was broken - it was fixed yesterday.

Just as a side note: maybe you should change your thread title to "I don't know whether to blame pacman, a package or myself"

phrakture · 2005-08-31 15:31:07

dibble:
I'd suggest adding backup=(etc/rc.conf etc/rc.local) to the package....

dtw · 2005-08-31 15:42:01

Phrak: I'm somewhat insulted, you could have ate least checked first!

backup=(etc/inittab etc/rc.conf etc/rc.local)

and it's always been that way

phrakture · 2005-08-31 16:00:33

dibblethewrecker wrote:

Phrak: I'm somewhat insulted, you could have ate least checked first!
backup=(etc/inittab etc/rc.conf etc/rc.local)
and it's always been that way

Hah... I was being lazy - I get tired of people screwing this up, didn't know you already did that.

Here's the rundown people:
the initscripts packages does not know about the initscripts-gensplash package. The initscripts-gensplash *does* know about the initscripts package.
Therefore, when initscripts-gensplash replaces initscripts, it knows exactly what to do and what to backup. The other way around, the iniscripts do not know they are replacing another package.

The only way I can think to handle this, is to add pre_remove logic to initscripts-gensplash that copy the files to something like /etc/pacbak/...

dtw · 2005-08-31 16:06:19

eh, surely rc.conf and rc.local should be saved regardless? Then as long as you remeber to install new initscripts then your fine...right?

phrakture · 2005-08-31 16:48:36

dibblethewrecker wrote:

eh, surely rc.conf and rc.local should be saved regardless? Then as long as you remeber to install new initscripts then your fine...right?

Well, that's obviously not happening. Rather than blame it on pacman, we can fix it now.

I think this has to do with what I tried to explain... initscripts->initscripts-gensplash works fine, because your PKGBUILD takes initscripts into account. However initscripts-gensplash->initscripts fails like this because initscripts has no notion of your package.

I say just force the backup with some output:

==> Due to issues with uninstalling initscripts-gensplash
==> your rc.conf and rc.local files have been copied to
==> /etc/pac_bak in case of any issues.  This will be
==> removed when the issue is sorted out.  Thanks.
... copying rc.conf/rc.local

dtw · 2005-08-31 17:54:29

Can't I move them to .pacsave?

laddiebuck · 2005-08-31 18:30:35

Dibblethewrecker -- I certainly won't add "or myself" to the topic title, as it's inaccurate. I understand you will now be fixing the package to save stuff to .pacsave (as /etc/inittab, fortunately, was saved) but the version of the package I had was broken.

By the way, I was also annoyed when the package initially overwrote my /etc/rc.sysinit without making a backup. I had rewritten my /etc/rc.sysinit completely. Since then I've marked it as a NoUpgrade, of course.

[edit] One other aspect of the behavior is that when initscripts-gensplash was uninstalled, it forgot to put back the old initscripts. Thus if I hadn't noticed the system would have been unbootable.

Last thing: /etc/pacman.conf had this line before I installed the initscripts-gensplash package:
NoUpgrade = etc/rc.conf etc/rc.local etc/rc.sysinit

Why then did initscripts-gensplash overwrite those, instead of just printing a warning to add some lines to them?

phrakture · 2005-08-31 18:49:09

dibble: go ahead and move them to pacsave if you want. But I was specifying the backup thing just to make it easier to track....

laddiebuck wrote:

Dibblethewrecker -- I certainly won't add "or myself" to the topic title, as it's inaccurate. I understand you will now be fixing the package to save stuff to .pacsave (as /etc/inittab, fortunately, was saved) but the version of the package I had was broken.

This is a very pompous statement. I can easilly say that by replacing the official initscripts package, you accepted the risks, which makes "or myself" entirely accurate.

laddiebuck wrote:

By the way, I was also annoyed when the package initially overwrote my /etc/rc.sysinit without making a backup. I had rewritten my /etc/rc.sysinit completely. Since then I've marked it as a NoUpgrade, of course.

IIRC pacman isn't handling NoUpgrade correctly at current. sysinit is not marked to be backed up because it is not a file which should be configured by a user. That's like saying "I'm irritated that the new pacman overwrote my changes in the makepkg script".

edit: you are aware that names mean nothing as far as init goes, correct? Why not make a "rc.laddiebuck" and replace rc.sysinit with that file in /etc/inittab - that way you have your script, which pacman will never overwrite, and you still have rc.sysinit.

laddiebuck wrote:

[edit] One other aspect of the behavior is that when initscripts-gensplash was uninstalled, it forgot to put back the old initscripts. Thus if I hadn't noticed the system would have been unbootable.

That's your job. If you can explain to me how pacman is supposed to know that the initscripts package should always be there, then go ahead. As it stands, pacman isn't a "nanny" - it is a package manager and does what you tell it to. I could easilly "pacman -R kernel26" and leave my system unbootable too. Pacman will not say "looks like you uninstalled your kernel... would you like to install a different one?"

laddiebuck · 2005-08-31 19:44:58

I'm not trying to be pompous. You're right, initscripts-gensplash is a "community" package, so I was at risk at installing it. Still, it is the package maintainer's fault rather than the user's. If I accept a present from someone and it blows up on me, it's not my fault. I agree I have no right to complain, as I got it for free out of someone's goodwill, but at least don't blame me for accepting it. Anyways, this discussion is pretty irrelevant to the main issue, which has got resolved.

Yes, I wasn't complaining that the installation overwrote my /etc/rc.sysinit. I had just mentioned that, maybe I shouldn't have.

Yes, the rc.laddiebuck is a good idea, I'll adopt that.

If the concept of system-critical packages doesn't exist in pacman, then maybe it should be added. There are certain packages for which there is no inconceivable benefit in allowing them to be removed. Sure, an advanced user might want to, but you could just give the advanced user a chance to do it in pacman.conf. The concept of system-critical packages that by default can't be removed is definitely a good one, and exists in some other package managers.

dtw · 2005-08-31 20:08:27

laddiebuck wrote:

I'm not trying to be pompous. You're right, initscripts-gensplash is a "community" package, so I was at risk at installing it. Still, it is the package maintainer's fault rather than the user's.

Um...no...you still don't get it. That pkg does EVERYTHING it is supposed to do. If I make the changes that phrakture is suggesting then I would be making allowances that SHOULD NOT be necessary. Seeing as you are the FIRST person to complain of this I think I can safely claim that this is an isolated incident. I am at no fault at all.

There IS a warning that tells you to reinstall the regular initscripts when you remove the gensplash scripts but it WAS broken - so I do apologise for that BUT, yet again, it's not actually my responsibility to do that.

As phrakture said pacman IS doing so pretty weird stuff when it comes to backing up at the moment. The backup line in the initscripts-gensplash PKGBUILD SHOULD save rc.conf, rc.local and inittab.

Personally I think these problems with pacman are a much higher priority than some of the current dev activties but what I think doesn't matter. The fact is that the issues really only come into play with system critical pkgs and initscripts-gensplash is the only custom one of those about.

By-the-way, if you install, unistall, reinstall without moving the backed up config files back to the correct location in between then that can overwrite your configs too...sure that didn't happen?

phrakture · 2005-08-31 20:09:36

laddiebuck wrote:

If the concept of system-critical packages doesn't exist in pacman, then maybe it should be added. There are certain packages for which there is no inconceivable benefit in allowing them to be removed. Sure, an advanced user might want to, but you could just give the advanced user a chance to do it in pacman.conf. The concept of system-critical packages that by default can't be removed is definitely a good one, and exists in some other package managers.

But why add the complication? Also, why take away the option? What if I wrote my own init system (or used initng)? I could safely remove the initscripts package. What if I build my own kernel? I could safely remove kernel26. What if I built the entire thing from scratch and was using pacman only to manage higher level applications?

To me, this is not a problem, it is a feature. You're only upset about it because you got caught by it. It's the same when lilo users forget to rerun lilo on an upgrade - "stupid lilo, it's all your fault". Problem is, arch is about giving the user full control over his system. There is no automation. There is only the user to blame.

I know for a fact I've never had a problem because I fully uninstalled the initscripts or the kernel, because I'm careful. If you're not too sure of what you're doing, maybe something like synaptic would be better.

laddiebuck · 2005-08-31 20:40:07

I did make a provision for that -- advanced users can specify that for themselves.

What I'm driving at is, that this problem can be architecturally solved with both of us happy. Suppose you specify an interface or category 'initialization programs'. Then one of the following would be an option: use sysvinit as the program, use initng as the program, or use bashinit (just a dummy package, a symlink from /sbin/init to /bin/sulogin or /bin/sh). Then make sure that that has to exist on the system. Thus the user has a choice between what they want to run, and even running "nothing" is an option. (In fact, a terribly advanced user could even manually take out "initialization programs" if they really wanted to, but what's the need with what I've described?)

My view is that a well-designed package management system is perfectly flexible enough to accomodate both "choice", and "safety". I put those terms in quotes deliberately, but I hope you see what I'm driving at. Such a solution wouldn't be against The Arch Way, but at least would provide some simple safeguards against common errors.

dibblethewrecker --
I may be the first to complain of it, but as Arch grows larger, I bet you I'm not the last either. I agree though that it's not your fault, but maybe in pacman's handling of the issue. (Hence the topic title.)

I didn't install, uninstall, and reinstall; I just installed and uninstalled inistscripts-gensplash. Then I reinstalled plain initscripts, and put my own changes back.

dtw · 2005-08-31 21:09:39

But when you install my initscripts did you move your old files back before uninstalling and reinstalling the next one? I'm sure you did - but it's worth asking

phrakture · 2005-08-31 21:48:11

Ok, I see all this "a good package manager does X" and "as arch grows larger Y".

We get someone like this every so often. A new fly-by-nighter come from gentoo/slackware/whatever and compares everything to they way their old distro worked.

They usually stick around for a bit, argue a lot, and then are never heard from again.

Mr Laddie, it appears that you have misunderstood the Archlinux philosophy. The suggestion to have a set of system critical packages would undermine much of the simplicity, elegance, and user control that is Arch. It's much along the lines of suggesting dependancy handling in the initscripts. It's just not needed.

I'm not trying to be an ass when I say this, I'm trying to save you some time - Arch linux isn't for you. This is one of those distros you either "get" or you don't.

laddiebuck · 2005-08-31 21:48:38

Yes, I did.

[edit] Saw phrakture's reply.

phrakture -- that was a remarkably snobbish post, whether you wanted it to be one or not. Arch is my favorite distribution so far, and I can handle it when things blow up for some reason. But please don't think that you in any way represent The Arch Way, or that you are somehow entitled to a perfect understanding of the Arch philosophy. In fact, the Arch philosophy doesn't really exist, because it's only a collective agreement in interpretation of a few rules that the core developers set down. If you probed it hard enough, I'm sure you could even get core developers to disagree on some issues that would seem to be covered by The Arch Way.

Simplicity is often the best design, but not always. Are you sure "The Arch Way" is a slavish insistence on simplicity even if there a slightly more complex solution would be better? Heck, that's not true. I'm sure some people would even find the rc.single and rc.multi system unnecessary -- I certainly did delete those files.

I don't see why the idea I proposed is too complicated. Maybe you could show me, or maybe you could actually contemplate it as an IDEA, divorced from YOUR ideas of philosophy. Thank you.

Cam · 2005-09-01 09:38:32

Rather than carry this on, perhaps you should agree to disagree which is a perfectly reasonable thing to do. Laddiebuck, go sign up at the bug tracker and file a feature request and leave it up to the devs, it's ultimately Judd's decision what gets included in pacman so try your luck.

phrakture · 2005-09-01 15:19:04

Cam wrote:

Rather than carry this on, perhaps you should agree to disagree which is a perfectly reasonable thing to do. Laddiebuck, go sign up at the bug tracker and file a feature request and leave it up to the devs, it's ultimately Judd's decision what gets included in pacman so try your luck.

Thank you Cam, you slapped me back into it. I was letting this thread get to me. Fact of the matter is I've proposed numerous things which are similar in nature to this, and all have been shot down.
a) something to indicate a "module" so that pacman will not upgrade the kernel package unless the module packages are also upgraded to match
b) an empty "base" package which depends on all the base packages (i.e. initscripts) - this way the base packages do not show up in the -Qe output.

laddiebuck, I apologize if I sounded snobbish. I didn't mean to come off that way, I meant to be helpful. It happens sometimes - someone once asked me where to read about something and I told him "www.google.com" - a few hours later he came back and said "hey thanks for telling me to go to google". So you never know. I had a feeling the guy would have been offended.

Arch Linux

#1 2005-08-31 00:19:14

I don't know whether to blame pacman or a package

#2 2005-08-31 01:14:15

Re: I don't know whether to blame pacman or a package

#3 2005-08-31 01:54:04

Re: I don't know whether to blame pacman or a package

#4 2005-08-31 01:58:17

Re: I don't know whether to blame pacman or a package

#5 2005-08-31 03:04:21

Re: I don't know whether to blame pacman or a package

#6 2005-08-31 04:13:13

Re: I don't know whether to blame pacman or a package

#7 2005-08-31 05:54:36

Re: I don't know whether to blame pacman or a package

#8 2005-08-31 08:12:00

Re: I don't know whether to blame pacman or a package

#9 2005-08-31 15:31:07

Re: I don't know whether to blame pacman or a package

#10 2005-08-31 15:42:01

Re: I don't know whether to blame pacman or a package

#11 2005-08-31 16:00:33

Re: I don't know whether to blame pacman or a package

#12 2005-08-31 16:06:19

Re: I don't know whether to blame pacman or a package

#13 2005-08-31 16:48:36

Re: I don't know whether to blame pacman or a package

#14 2005-08-31 17:54:29

Re: I don't know whether to blame pacman or a package

#15 2005-08-31 18:30:35

Re: I don't know whether to blame pacman or a package

#16 2005-08-31 18:49:09

Re: I don't know whether to blame pacman or a package

#17 2005-08-31 19:44:58

Re: I don't know whether to blame pacman or a package

#18 2005-08-31 20:08:27

Re: I don't know whether to blame pacman or a package

#19 2005-08-31 20:09:36

Re: I don't know whether to blame pacman or a package

#20 2005-08-31 20:40:07

Re: I don't know whether to blame pacman or a package

#21 2005-08-31 21:09:39

Re: I don't know whether to blame pacman or a package

#22 2005-08-31 21:48:11

Re: I don't know whether to blame pacman or a package

#23 2005-08-31 21:48:38

Re: I don't know whether to blame pacman or a package

#24 2005-09-01 09:38:32

Re: I don't know whether to blame pacman or a package

#25 2005-09-01 15:19:04

Re: I don't know whether to blame pacman or a package

Board footer