Actually, these should be in /sbin not /

pam stuff had been taken care of ...

commits
c6d10acd1a2110830913b9af0dc9be35df8e5d67
e2eafbe435eb9bc78df80a32e2462c1a2064d9f3

follow FHS that demands gzip and cpio in /bin
and commit

628b3937a5fe15b502d2273e087b04f2f4caee73

adds bzip2 to that party - it is not mentioned in FHS but shall be in /bin for 
the same reason as gzip, which is being replaced by bzip2 for some (quite a 
few) ppl.

What is missing to close this bug is an answer to the question if we want to 
undertake the effort to provide a usable $EDITOR in /bin based on admin's 
choice (change install dir of the TEXT-EDITOR provider if it was chosen in 
basesystem? is that feasible / good?).

No.  Why would we need to do this for the admin?  They are big boys (and girls),
they can change --bindir if they want to.  If we are too worried they won't
think of it, we can throw a query at them to remind them.

If FHS demands something in /bin or /sbin, fine (for now), but pay attention to
"must be installed at" vs "if installed, must be available at".  Otherwise,
please stay out of my / partition.  Thanks.

Well, I'll modify that a bit.  If upstream wants to install in /bin and our
sorcery default_build is moving it to /usr, that's a problem that should get
resolved.

>If FHS demands something in /bin or /sbin, fine (for now), but pay attention 
>to
>"must be installed at" vs "if installed, must be available at".

Meaning: If source package installs in /usr/bin per default and FHS 
says "shall be available" we do not change the install but place a symlink?

Well, but for the system tools needed to restore from / without /usr symlinks 
won't do it, obviously;-)

>No.  Why would we need to do this for the admin?  They are big boys (and 
>girls),
>they can change --bindir if they want to.
Depends on the editor, not every package has a configure option for that. Not 
every package has a configure.
Well, but faced with the immense desire for choice concerning $EDITOR, we 
should perhaps leave it as is.
This friend of mine has his own spell of vim for an older version that acceps 
his patching anyway... so he can make this spell isntall a working vim 
into /bin or better even just /root/bin to give users a chance to use "normal" 
vim.

Hm, do we consider this bug closed now or do we have other voices on the 
$EDITOR question?

(In reply to comment #7)
> >If FHS demands something in /bin or /sbin, fine (for now), but pay attention 
> >to
> >"must be installed at" vs "if installed, must be available at".
> 
> Meaning: If source package installs in /usr/bin per default and FHS 
> says "shall be available" we do not change the install but place a symlink?

Normally, yes, but...

> Well, but for the system tools needed to restore from / without /usr symlinks 
> won't do it, obviously;-)

...but for these it probably does make sense to put them really in /bin, for the
reasons noted.

> >No.  Why would we need to do this for the admin?  They are big boys (and 
> >girls),
> >they can change --bindir if they want to.
> Depends on the editor, not every package has a configure option for that. Not 
> every package has a configure.

We still don't move it.  User choice, FHS, upstream, in that order.  No "what we
think makes sense" aka "sensible defaults".
 
> Hm, do we consider this bug closed now or do we have other voices on the 
> $EDITOR question?

I'm skeptical you should have moved bzip2.  Upstream only even puts it in
/usr/local and no matter how used it is it's not enough to have made FHS require
it in /bin yet.  If we start deciding things are "used enough" ourselves we
start adding all kinds of things and that's not our job.

Well, upstream puts it into /usr/local as that is some default for software to 
be added to an installed system out-of-distro.
Actually, any default for some end-user tool is normally /usr/local as that 
fits the situation of adding some software to an existing system out of line.
Distributions are not supposed to follow that for the standard system files.
So for the particular question of where to put the binary or even the files in 
general (it is very reasonable to change the prefix to /usr for _many_ 
packages), upstream defaults is really the wrong thing to look at.

Anyhow, I peeked around a little:

LFS places bzip into /bin .
SuSE places it into /usr/bin .
Debian has it in /usr/bin in stable but changed that to /bin when you look at 
testing .

So we would be in good company with LFS and Debian with the decision to 
interpret the FHS in a way that bzip2 has a place in /bin .
What we could do (more work...) is to add a  configure option to a list of 
possible core spells for installing their binaries (and perhaps libs) 
into /bin (or /lib) ... we kindof have this option with spells where --bindir 
works, but bzip2 already needed some hacking in Makefile.
But does it really hurt anyone with putting bzip2 into /bin ?
It doesn't violate the words of FHS, while complying with the spirit.

(In reply to comment #9)
> Well, upstream puts it into /usr/local as that is some default for software to 
> be added to an installed system out-of-distro.

Yes, I'm aware what /usr/local, I just meant upstream isn't useful in this case.
 
> Anyhow, I peeked around a little:
> 
> LFS places bzip into /bin .
> SuSE places it into /usr/bin .
> Debian has it in /usr/bin in stable but changed that to /bin when you look at 
> testing .
> 
> So we would be in good company with LFS and Debian with the decision to 
> interpret the FHS in a way that bzip2 has a place in /bin .

The commitment we make to our users is not "to be in good company", it is that
we will not mess with their system without asking them, and they will get the
same thing they'd get installing directly from upstream apart from file location
changes necessary to comply with FHS.

> What we could do (more work...) is to add a  configure option to a list of 
> possible core spells for installing their binaries (and perhaps libs) 
> into /bin (or /lib) ... we kindof have this option with spells where --bindir 
> works, but bzip2 already needed some hacking in Makefile.

If bzip2 doesn't work with it's own ./configure options it's a bug for upstream
to fix.

> But does it really hurt anyone with putting bzip2 into /bin ?
> It doesn't violate the words of FHS, while complying with the spirit.

Why not bzip2?  Why not grep?  Why not find?  Why not all of coreutils?  Why not
man, a web browser, and an ftp client, just in case they're stuck and need some
docs?  It's a slippery slope I just don't want to be on.  I'm sure I sound like
a pedant but our users are pedants, they like us for being pedants.  The
appropriate decision-making body for this, as much as there is one, is FHS, not us.

(In reply to comment #10)
> (In reply to comment #9)
> > Well, upstream puts it into /usr/local as that is some default for software to 
> > be added to an installed system out-of-distro.
> 
> Yes, I'm aware what /usr/local, I just meant upstream isn't useful in this case.

This decision could even be argued, although we've pretty much decided that all
our packages won't install into /usr/local. We leave that to the local admin and
stuff not managed by sorcery.

>  
> > Anyhow, I peeked around a little:
> > 
> > LFS places bzip into /bin .
> > SuSE places it into /usr/bin .
> > Debian has it in /usr/bin in stable but changed that to /bin when you look at 
> > testing .
> > 
> > So we would be in good company with LFS and Debian with the decision to 
> > interpret the FHS in a way that bzip2 has a place in /bin .
> 
> The commitment we make to our users is not "to be in good company", it is that
> we will not mess with their system without asking them, and they will get the
> same thing they'd get installing directly from upstream apart from file location
> changes necessary to comply with FHS.

Yep. Upstream, or if upstream isn't "correct" according to FHS. That's it. I'm
somewhat glad we're not "in good company" with debian.

> 
> > What we could do (more work...) is to add a  configure option to a list of 
> > possible core spells for installing their binaries (and perhaps libs) 
> > into /bin (or /lib) ... we kindof have this option with spells where --bindir 
> > works, but bzip2 already needed some hacking in Makefile.
> 
> If bzip2 doesn't work with it's own ./configure options it's a bug for upstream
> to fix.

Yep. And one could argue that bzip2 isn't needed to restore a system anyway.
There's always a live CD. If you're hosed in such a way to need bzip2, you
probably should use a liveCD anyway.

> 
> > But does it really hurt anyone with putting bzip2 into /bin ?
> > It doesn't violate the words of FHS, while complying with the spirit.
> 
> Why not bzip2?  Why not grep?  Why not find?  Why not all of coreutils?  Why not
> man, a web browser, and an ftp client, just in case they're stuck and need some
> docs?  It's a slippery slope I just don't want to be on.  I'm sure I sound like
> a pedant but our users are pedants, they like us for being pedants.  The
> appropriate decision-making body for this, as much as there is one, is FHS,
not us.

Yeah, this is the problem. We can't do this for the users. Then we start
deciding what's best. That's bad. We don't do that. If you feel that you need
this done on your system it's easy to modify INSTALL_ROOT to put the stuff where
you want it to go.

On a side note, I'm usually able to recover almost any system without /usr being
mounted. One, because I can mount /usr by hand, then use whatever it is I
needed. Or I use a live CD. 

Although this might seem like a good idea, it's not what Source Mage is about.

This is starting to look like an ML thread...

(In reply to comment #11)
> (In reply to comment #10)
> > Yes, I'm aware what /usr/local, I just meant upstream isn't useful in this case.
> 
> This decision could even be argued, although we've pretty much decided that all
> our packages won't install into /usr/local. We leave that to the local admin and
> stuff not managed by sorcery.

My pie-in-the-sky is to eventually have a sorcery option that is "apply FHS
prefixes" or "leave it as upstream" or "set my own prefix/bindir/etc.".  This
setting would affect what default_build did and spells that had to roll their
own install locations would consult it.  But we'd probably say we only supported
the FHS variant and make that the default.

That's messianic, though, and we have much better things to do without creating
that as extra work.



So: please go ahead and roll the bzip2 one back.  If you want to look for other
places FHS says things go in /bin and we don't comply and add them to this bug,
great, otherwise I think it's done.

This was thought before Jeremy's last message, should still apply...

> If bzip2 doesn't work with it's own ./configure options it's a bug for 
upstream
> to fix.

Eh, I cannot report to upstream that their --bindir configure option doesn't 
work since there _is_ _no_ configure;-)

Also FHS does not say a word on where to put bzip2. You have to guess and make 
an own decision - the SMGL decision is then to put nothing but the explicitly 
mentioned stuff into /bin, apparently.
By the way, I'm glad we have dmsetup in /sbin despite of it not being 
mentioned in FHS and upstream defaulting to /usr (not local).
It is a sensible thing to do, considering that one may need a run of dmsetup 
to get the device /usr relies on...

And, David, I guess you realize (when reading this, at least;-) that 
INSTALL_ROOT won't help anything in /bin vs. /usr/bin ...

With the live CD argument, you set off the people without cd boot ability.
Heck, it could be just that your network is down (and thus /usr since it is a 
shared /usr network environment) and you have a minimal rescue tar.bz2 of /usr 
on some other place and could unpack it when bzip is there.
But well, we want to let the FHS guys decide what's good - while they haven't 
actually decided on bzip2 ... aaaand they're (I guess) the same guys who made 
FHS 2.3 which we do not consider to be the absolute truth for some reason.

Well, I'm tired of arguing here, can we settle on me turning the /bin support 
in bzip2 into an opt-in in CONFIGURE?

And in case my friend will ever convert to vim 7 in our grimoire, I know he 
will want it in /bin ... and what a relief, give it --exec-prefix= and:

/bin
/bin/ex
/bin/rview
/bin/rvim
/bin/view
/bin/vim
/bin/vimdiff
/bin/vimtutor
/bin/xxd
/etc
/etc/profile.d
/etc/profile.d/editor.sh
/usr
/usr/bin
/usr/bin/vi
...
well, the last one being a broken symlink now, but that was out spell, not 
vim's install.
This way vim works perfectly without /usr; just for additional colors 'n' 
comfort it needs /usr/share/vim.

So, most GNU-like stuff can be worked into /bin and /sbin by the CONFIG_LOCAL 
feature as admin requests. That's fine.
I hope it is just fair to add this possibility to spells that don't have it 
the automagic way: Make default bzip2 to /usr/bin, add query about installing 
to /bin .

(In reply to comment #13)
> > If bzip2 doesn't work with it's own ./configure options it's a bug for 
> upstream
> > to fix.
> 
> Eh, I cannot report to upstream that their --bindir configure option doesn't 
> work since there _is_ _no_ configure;-)

:-(

I might still file a bug with upstream to get into the 19100's and autotool it.  ;-P

> Also FHS does not say a word on where to put bzip2. You have to guess and make 
> an own decision - the SMGL decision is then to put nothing but the explicitly 
> mentioned stuff into /bin, apparently.

Yes, there is nothing new here... and this isn't a pointless distinction. 
Admins may well want / kept very small, we don't help that by putting extra
binaries and libraries there.

> By the way, I'm glad we have dmsetup in /sbin despite of it not being 
> mentioned in FHS and upstream defaulting to /usr (not local).
> It is a sensible thing to do, considering that one may need a run of dmsetup 
> to get the device /usr relies on...

Heh, I put it there but I shouldn't have done it without a query, though I'd
agree this one is more grey than most since it's part of every boot once
installed.  Regardless, I should add a query...

> But well, we want to let the FHS guys decide what's good - while they haven't 
> actually decided on bzip2 ... aaaand they're (I guess) the same guys who made 
> FHS 2.3 which we do not consider to be the absolute truth for some reason.

Yeah but there are other bugs filed to fix that.  That decision predates a lot
of us and doesn't make for a lot of consistency IMO either.

> Well, I'm tired of arguing here, can we settle on me turning the /bin support 
> in bzip2 into an opt-in in CONFIGURE?

Yes.

> I hope it is just fair to add this possibility to spells that don't have it 
> the automagic way: Make default bzip2 to /usr/bin, add query about installing 
> to /bin .

Typically any queries are fair as long as it's not just some abstract feature
very few will want and can just get through CONFIG_LOC anyway.  Install location
for something like this that doesn't have CONFIG_LOC available is probably a
necessity. 

OK, then we have the meat of this bug settled.
The query is in. I'll perhaps ask the bzip2 folks about adding the EPREFIX 
support to the distributed Makefile - I really doubt they want to go through 
the hassle of autoconf for that small and self-contained program.
A fake configure script would be more like it, perhaps.

Anyhow... closing this bug after having come to a conclusion - thanks to the 
crowd for the lively discussion.

closing fixed bugs

reassign to sm-grimoire-bugs

Changing version to test grimoire.