need opinions from sysadmins on where reiser4progs should install

need opinions from sysadmins on where reiser4progs should install

[Hans Reiser]

currently it installs mkfs.reiser4 and such in /usr/local/sbin

This is not found by default paths for most roots, and seems unlikely to
be where I would want it to go if I was sysadmin....  I would never
install mkfs.anything unless I wanted it in /sbin.....  but then I am
not a professional....

What do the sysadmins on the list think?

Hans

Re: need opinions from sysadmins on where reiser4progs should install

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Hans Reiser wrote:
> currently it installs mkfs.reiser4 and such in /usr/local/sbin
> 
> This is not found by default paths for most roots, and seems unlikely to
> be where I would want it to go if I was sysadmin....  I would never
> install mkfs.anything unless I wanted it in /sbin.....  but then I am
> not a professional....
> 
> What do the sysadmins on the list think?

I am not a sysadmin but I think the current scheme is good. After all
the user could have reiser4progs installed by the distribution in /sbin,
which would be overridden. If the user really wants to manually install
the program to /sbin, he should use the appropriate ./configure options.

Regards,
Petteri Räty


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: need opinions from sysadmins on where reiser4progs should install

[Gorazd Golob]

re!

I guess that according to LSB it's the only way - to install it into 
/usr/local/sbin - because it's additional installed software and does not 
come with default distribution.
If reiser4progs is package included in distribution then it should be 
installed /sbin or /usr/sbin.

that's my opinion - lsb is covering that topic as I know.

gorazd



On Sat, 12 Nov 2005, Hans Reiser wrote:

> currently it installs mkfs.reiser4 and such in /usr/local/sbin
>
> This is not found by default paths for most roots, and seems unlikely to
> be where I would want it to go if I was sysadmin....  I would never
> install mkfs.anything unless I wanted it in /sbin.....  but then I am
> not a professional....
>
> What do the sysadmins on the list think?
>
> Hans
>
>
>

Re: need opinions from sysadmins on where reiser4progs should install

[Clifford Beshers]

http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES

Hans Reiser wrote:

>currently it installs mkfs.reiser4 and such in /usr/local/sbin
>
>This is not found by default paths for most roots, and seems unlikely to
>be where I would want it to go if I was sysadmin....  I would never
>install mkfs.anything unless I wanted it in /sbin.....  but then I am
>not a professional....
>
>What do the sysadmins on the list think?
>
>Hans
>
>
>  
>

Re: need opinions from sysadmins on where reiser4progs should install

[Tom Vier]

On Sat, Nov 12, 2005 at 11:17:37PM -0800, Hans Reiser wrote:
> What do the sysadmins on the list think?

Doesn't matter to me, fwiw. If i were to build it manually, i'd run
./configure --prefix=/usr/local. A distribution would use --prefix=/ in its
build scripts. /usr/local might be a safer default, so that if someone's
installing it from source it would clobber their distro's version by
default.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE

Re: need opinions from sysadmins on where reiser4progs should install

[Hubert Chan]

On Sat, 12 Nov 2005 23:17:37 -0800, Hans Reiser <reiser@namesys.com> said:

> currently it installs mkfs.reiser4 and such in /usr/local/sbin This is
> not found by default paths for most roots, and seems unlikely to be
> where I would want it to go if I was sysadmin....  I would never
> install mkfs.anything unless I wanted it in /sbin.....  but then I am
> not a professional....

> What do the sysadmins on the list think?

I am not a sysadmin, but I would think that anyone who's smart enough to
compile from source is also smart enough to add /usr/lecal/sbin to their
path, or override the defaults.

Also, the Filesystem Hierarchy Standard (FHS) wants locally-build
software to go into /usr/local.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: need opinions from sysadmins on where reiser4progs should install

[Hans Reiser]

Clifford Beshers wrote:

> http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
>
> Hans Reiser wrote:
>
>> currently it installs mkfs.reiser4 and such in /usr/local/sbin
>>
>> This is not found by default paths for most roots, and seems unlikely to
>> be where I would want it to go if I was sysadmin....  I would never
>> install mkfs.anything unless I wanted it in /sbin.....  but then I am
>> not a professional....
>>
>> What do the sysadmins on the list think?
>>
>> Hans
>>
>>
>>  
>>
>
>
well, this says /sbin as I read it.  Thanks for the URL Clifford!

Re: need opinions from sysadmins on where reiser4progs should install

[Paul Jarc]

Hans Reiser <reiser@namesys.com> wrote:
> Clifford Beshers wrote:
>> http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
>
> well, this says /sbin as I read it.  Thanks for the URL Clifford!

The FHS doesn't specify what the default installation prefix for a
source tarball should be.  That section says that distributions should
install certain things in /sbin or /usr/sbin, and that admins who
install similar things independently of the distribution should use
/usr/local/sbin.  Obviously that doesn't work in some cases, but that
is what the FHS says: distributions and admins should choose those
respective locations, regardless of the package's default.

Since distributions' installations are typically automated and so can
easily specify a non-default prefix, source tarballs generally default
to /usr/local for the admins.  As a result, admins will expect the
default to be /usr/local, and they know how to use --prefix=/ if
that's what they want.  The principles of least surprise and least
damage suggest that the default for reiser4progs should be /usr/local,
just like every other package, *even if that means the default will
rarely be used*.

For myself, I only care that an explicit --prefix is used for every
installed file, since I install to a different directory anyway.


paul

Re: need opinions from sysadmins on where reiser4progs should install

[Philippe Gramoullé]

Hello Hans,

On Sat, 12 Nov 2005 23:17:37 -0800
Hans Reiser <reiser@namesys.com> wrote:

  | What do the sysadmins on the list think?
  | 
  | Hans

Personally, for Reiserfs V3, i always compiled reiserfsprogs statically and installed
the tools in /sbin.

Mainly because, we used to have /usr on a separate partition on all server installs.

So should a crash occur and /usr becomes corrupted, well, at least / is mounted and i could
reiserfsck partitions right away, handy when the server is several thousand kilometers away :)

I expect to do the same for reiser4progs, so i wish that reiser4progs utilities would install
in /, and as such /sbin seems the best choice _to me_

Thanks

Philippe

PS: I hope that Santa will bring me a brand new kernel.org kernel with reiser4 in :)
    Good luck with that, and congratulations to you and the whole team for such a nice
    filesystem

Re: need opinions from sysadmins on where reiser4progs should install

[rvalles]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On Thu, Nov 17, 2005 at 05:06:43PM +0100, Philippe Gramoullé wrote:
> So should a crash occur and /usr becomes corrupted, well, at least / is mounted and i could
> reiserfsck partitions right away, handy when the server is several thousand kilometers away :)
> 
> I expect to do the same for reiser4progs, so i wish that reiser4progs utilities would install
> in /, and as such /sbin seems the best choice _to me_

When I run make install on something and haven't specified a prefix on
configure, I expect /usr/local to be used. If I wanted /, I'd have
specified that on configure time. If it installed in / by default, it
would, often, hit the "sacred package-system managed area" of the VFS
tree annoying people like me to a very great extend, so please don't.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: need opinions from sysadmins on where reiser4progs should install

[Philippe Gramoullé]

Hello,

On Sun, 20 Nov 2005 05:07:23 +0100
rvalles <rvalles@es.gnu.org> wrote:

  | When I run make install on something and haven't specified a prefix on
  | configure, I expect /usr/local to be used. If I wanted /, I'd have
  | specified that on configure time. If it installed in / by default, it
  | would, often, hit the "sacred package-system managed area" of the VFS
  | tree annoying people like me to a very great extend, so please don't.

While i totally agree with you for standard packages, well i based my choice
on actual experience of the last past six years of use with reiserfs V3.

I can't remember how many times i heard Namesys team say " Install the latest
& greatest reiserfsck", how many times distro thought they knew reiserfsprogs
internals better than Namesys and customized it to the point where it would
eventually break.

Of course, i can live with a manual install of reiser(fs|4)progs, so i don't
really mind, but talking of support, it can make quite a difference to Namesys
in terms of support, and annoyance with bug reports that could have been easily
avoided.

Final decision will still be Namesys call, but hopefully this whole thread gave
them some valuable input to make the best decision.

Thanks,

Philippe

Re: need opinions from sysadmins on where reiser4progs should install

[Hans Reiser]

Philippe Gramoullé wrote:

>Hello,
>
>On Sun, 20 Nov 2005 05:07:23 +0100
>rvalles <rvalles@es.gnu.org> wrote:
>
>  | When I run make install on something and haven't specified a prefix on
>  | configure, I expect /usr/local to be used. If I wanted /, I'd have
>  | specified that on configure time. If it installed in / by default, it
>  | would, often, hit the "sacred package-system managed area" of the VFS
>  | tree annoying people like me to a very great extend, so please don't.
>
>While i totally agree with you for standard packages, well i based my choice
>on actual experience of the last past six years of use with reiserfs V3.
>
>I can't remember how many times i heard Namesys team say " Install the latest
>& greatest reiserfsck", how many times distro thought they knew reiserfsprogs
>internals better than Namesys and customized it to the point where it would
>eventually break.
>
>Of course, i can live with a manual install of reiser(fs|4)progs, so i don't
>really mind, but talking of support, it can make quite a difference to Namesys
>in terms of support, and annoyance with bug reports that could have been easily
>avoided.
>  
>
Ok, I propose the following: search the standard locations for where it
is currently, tell the user, ask the user if they want to rename those
versions to *.old if the install of the new one succeeds, and then
prompt for the install location with /sbin as the suggested default.  I
think that unlike other user installed programs, fsck does not belong in
/usr/local.  I think Philippe's point that old versions are dangerous is
quite valid.

>Final decision will still be Namesys call, but hopefully this whole thread gave
>them some valuable input to make the best decision.
>
>Thanks,
>
>Philippe
>
>
>  
>

Re: need opinions from sysadmins on where reiser4progs should install

[Hubert Chan]

On Sun, 20 Nov 2005 23:09:01 -0800, Hans Reiser <reiser@namesys.com> said:

> Ok, I propose the following: search the standard locations for where
> it is currently, tell the user, ask the user if they want to rename
> those versions to *.old if the install of the new one succeeds, and
> then prompt for the install location with /sbin as the suggested
> default.

One possible problem: if, for example, a user has reiser4progs installed
as a Debian package, then the new (user-installed) version would be
overwritten if the reiser4progs Debian package gets updated.  Whether
this is the desired result (e.g. if the new Debian package is a newer
version of reiser4progs) or not (e.g. if the new Debian is just a minor
bugfix on the old version of reiser4progs), I don't know.

So if you choose to do this, you may want to include a warning about the
above case.  Users probably shouldn't try to have both the
distribution-packaged reiser4progs, along with a locally-compiled
version, at the same time.

> I think that unlike other user installed programs, fsck does not
> belong in /usr/local.

fsck, probably not.  mkfs, maybe.

Another option is to default to /usr/local, to satisfy the principle of
least surprise for administrators who expect all locally-compiled
programs to be in /usr/local, but emit a very loud warning that "this is
probably not really what you want to do, and should only continue with
/usr/local if you know what you are doing" for the following reasons:

- having old versions of reiser4progs could be dangerous
- fsck will not be available until after /usr/local is mounted
- /usr/local/sbin is usually not on root's $PATH
- ...

> I think Philippe's point that old versions are dangerous is quite
> valid.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: need opinions from sysadmins on where reiser4progs should install

[Vitaly Fertman]

On Monday 21 November 2005 10:09, Hans Reiser wrote:
> Philippe Gramoullé wrote:
> 
> >Hello,
> >
> >On Sun, 20 Nov 2005 05:07:23 +0100
> >rvalles <rvalles@es.gnu.org> wrote:
> >
> >  | When I run make install on something and haven't specified a prefix on
> >  | configure, I expect /usr/local to be used. If I wanted /, I'd have
> >  | specified that on configure time. If it installed in / by default, it
> >  | would, often, hit the "sacred package-system managed area" of the VFS
> >  | tree annoying people like me to a very great extend, so please don't.
> >
> >While i totally agree with you for standard packages, well i based my choice
> >on actual experience of the last past six years of use with reiserfs V3.
> >
> >I can't remember how many times i heard Namesys team say " Install the latest
> >& greatest reiserfsck", how many times distro thought they knew reiserfsprogs
> >internals better than Namesys and customized it to the point where it would
> >eventually break.
> >
> >Of course, i can live with a manual install of reiser(fs|4)progs, so i don't
> >really mind, but talking of support, it can make quite a difference to Namesys
> >in terms of support, and annoyance with bug reports that could have been easily
> >avoided.
> >  
> >
> Ok, I propose the following: search the standard locations for where it
> is currently, tell the user, ask the user if they want to rename those

the proper service is already done in package managers. if one needs it, 
he can use one of them. 

> versions to *.old if the install of the new one succeeds, and then

this breaks the installed software consistency and may screw the package 
manager up...

> prompt for the install location with /sbin as the suggested default.  I
> think that unlike other user installed programs, fsck does not belong in
> /usr/local.  I think Philippe's point that old versions are dangerous is
> quite valid.

install to the system default through a system package manager;

install to the local default from source to not break the system installed
software consistency;

provide a way to install where a user wants if he knows what he does and 
if he remembers what and how has been installed on a particular system;

> >Final decision will still be Namesys call, but hopefully this whole thread gave
> >them some valuable input to make the best decision.
> >
> >Thanks,
> >
> >Philippe
> >
>

-- 
Vitaly

Re: need opinions from sysadmins on where reiser4progs should install

[Hans Reiser]

Vitaly Fertman wrote:

>On Monday 21 November 2005 10:09, Hans Reiser wrote:
>  
>
>>Philippe GramoullИ wrote:
>>
>>    
>>
>>>Hello,
>>>
>>>On Sun, 20 Nov 2005 05:07:23 +0100
>>>rvalles <rvalles@es.gnu.org> wrote:
>>>
>>> | When I run make install on something and haven't specified a prefix on
>>> | configure, I expect /usr/local to be used. If I wanted /, I'd have
>>> | specified that on configure time. If it installed in / by default, it
>>> | would, often, hit the "sacred package-system managed area" of the VFS
>>> | tree annoying people like me to a very great extend, so please don't.
>>>
>>>While i totally agree with you for standard packages, well i based my choice
>>>on actual experience of the last past six years of use with reiserfs V3.
>>>
>>>I can't remember how many times i heard Namesys team say " Install the latest
>>>& greatest reiserfsck", how many times distro thought they knew reiserfsprogs
>>>internals better than Namesys and customized it to the point where it would
>>>eventually break.
>>>
>>>Of course, i can live with a manual install of reiser(fs|4)progs, so i don't
>>>really mind, but talking of support, it can make quite a difference to Namesys
>>>in terms of support, and annoyance with bug reports that could have been easily
>>>avoided.
>>> 
>>>
>>>      
>>>
>>Ok, I propose the following: search the standard locations for where it
>>is currently, tell the user, ask the user if they want to rename those
>>    
>>
>
>the proper service is already done in package managers. if one needs it, 
>he can use one of them. 
>
>  
>
>>versions to *.old if the install of the new one succeeds, and then
>>    
>>
>
>this breaks the installed software consistency and may screw the package 
>manager up...
>  
>
Sigh, good point, ok, well then at least warn the user about them.

>  
>
>>prompt for the install location with /sbin as the suggested default.  I
>>think that unlike other user installed programs, fsck does not belong in
>>/usr/local.  I think Philippe's point that old versions are dangerous is
>>quite valid.
>>    
>>
>
>install to the system default through a system package manager;
>
>install to the local default from source to not break the system installed
>software consistency;
>  
>
So the reason for not installing to /sbin is to avoid messing up the
package manager?  I regret to say it makes sense.  If that is the
reason, then warn the user please about old versions left intact, and
suggest they be removed, and prompt the user for the path to install to
and remind them to update their $PATH.

>provide a way to install where a user wants if he knows what he does and 
>if he remembers what and how has been installed on a particular system;
>
>  
>
>>>Final decision will still be Namesys call, but hopefully this whole thread gave
>>>them some valuable input to make the best decision.
>>>
>>>Thanks,
>>>
>>>Philippe
>>>
>>>      
>>>
>
>  
>

Re: need opinions from sysadmins on where reiser4progs should install

[michael chang]

On 11/21/05, Hans Reiser <reiser@namesys.com> wrote:
> Vitaly Fertman wrote:
>
> >On Monday 21 November 2005 10:09, Hans Reiser wrote:
> >
> >
> >>Philippe Gramoullé wrote:
> >>
> >>
> >>
> >>>Hello,
> >>>
> >>>On Sun, 20 Nov 2005 05:07:23 +0100
> >>>rvalles <rvalles@es.gnu.org> wrote:
> >>>
> >>> | When I run make install on something and haven't specified a prefix on
> >>> | configure, I expect /usr/local to be used. If I wanted /, I'd have
> >>> | specified that on configure time. If it installed in / by default, it
> >>> | would, often, hit the "sacred package-system managed area" of the VFS
> >>> | tree annoying people like me to a very great extend, so please don't.
> >>>
> >>>While i totally agree with you for standard packages, well i based my choice
> >>>on actual experience of the last past six years of use with reiserfs V3.
> >>>
> >>>I can't remember how many times i heard Namesys team say " Install the latest
> >>>& greatest reiserfsck", how many times distro thought they knew reiserfsprogs
> >>>internals better than Namesys and customized it to the point where it would
> >>>eventually break.
> >>>
> >>>Of course, i can live with a manual install of reiser(fs|4)progs, so i don't
> >>>really mind, but talking of support, it can make quite a difference to Namesys
> >>>in terms of support, and annoyance with bug reports that could have been easily
> >>>avoided.
> >>>
> >>>
> >>>
> >>>
> >>Ok, I propose the following: search the standard locations for where it
> >>is currently, tell the user, ask the user if they want to rename those
> >>
> >>
> >
> >the proper service is already done in package managers. if one needs it,
> >he can use one of them.
> >
> >
> >
> >>versions to *.old if the install of the new one succeeds, and then
> >>
> >>
> >
> >this breaks the installed software consistency and may screw the package
> >manager up...
> >
> >
> Sigh, good point, ok, well then at least warn the user about them.
>
> >
> >
> >>prompt for the install location with /sbin as the suggested default.  I
> >>think that unlike other user installed programs, fsck does not belong in
> >>/usr/local.  I think Philippe's point that old versions are dangerous is
> >>quite valid.
> >>
> >>
> >
> >install to the system default through a system package manager;
> >
> >install to the local default from source to not break the system installed
> >software consistency;
> >
> >
> So the reason for not installing to /sbin is to avoid messing up the
> package manager?  I regret to say it makes sense.  If that is the
> reason, then warn the user please about old versions left intact, and
> suggest they be removed, and prompt the user for the path to install to
> and remind them to update their $PATH.
>

The problem is that some package managers might make reiser4progs a
"base" package, which removing will emit a loud warning that it might
break your system.  That said, anyone installing a custom reiser4progs
may or may not be supposed to have the knowledge to work around it.

It'd be like the installing java mess all over again [times two] --
except for one difference... Java isn't essential.  Reiser4progs could
be.

It might be easier to make a pseudo-package representing the program
(e.g. the way Sun's JRE is "converted to a package" in Debian Sarge,
as well as the way older versions used an empty package file to
satisfy depends in Debian Woody; reiserfs would have a fake package in
the package manager when installed from source) or to actually put
package building scripts for package-handling distros in the source
package (or use something like checkinstall, provided it doesn't
conflict too bad).  [You can also did what Debian did with it's
'kernel-package' system; it provides a package specially designed for
converting a custom kernel into a package, so similarly, a
packaging-tool specific to that distro could be put in the distro. 
This lets users use any kernel source without having to use a
debianized source and still have a kernel package to install at the
end; so you can use the latest and greatest Reiser4Progs and the
Debian package manager without having to wait for a debianized
package.  Same or similar applies for other packaging distros.]

*sigh* How complicated...

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: need opinions from sysadmins on where reiser4progs should install

[David Masover]

michael chang wrote:
> On 11/21/05, Hans Reiser <reiser@namesys.com> wrote:
> 
>>Vitaly Fertman wrote:
>>
>>
>>>On Monday 21 November 2005 10:09, Hans Reiser wrote:
>>>
>>>
>>>
>>>>Philippe GramoullИ wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hello,
>>>>>
>>>>>On Sun, 20 Nov 2005 05:07:23 +0100
>>>>>rvalles <rvalles@es.gnu.org> wrote:
>>>>>
>>>>>| When I run make install on something and haven't specified a prefix on
>>>>>| configure, I expect /usr/local to be used. If I wanted /, I'd have
>>>>>| specified that on configure time. If it installed in / by default, it
>>>>>| would, often, hit the "sacred package-system managed area" of the VFS
>>>>>| tree annoying people like me to a very great extend, so please don't.
>>>>>
>>>>>While i totally agree with you for standard packages, well i based my choice
>>>>>on actual experience of the last past six years of use with reiserfs V3.
>>>>>
>>>>>I can't remember how many times i heard Namesys team say " Install the latest
>>>>>& greatest reiserfsck", how many times distro thought they knew reiserfsprogs
>>>>>internals better than Namesys and customized it to the point where it would
>>>>>eventually break.
>>>>>
>>>>>Of course, i can live with a manual install of reiser(fs|4)progs, so i don't
>>>>>really mind, but talking of support, it can make quite a difference to Namesys
>>>>>in terms of support, and annoyance with bug reports that could have been easily
>>>>>avoided.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>Ok, I propose the following: search the standard locations for where it
>>>>is currently, tell the user, ask the user if they want to rename those
>>>>
>>>>
>>>
>>>the proper service is already done in package managers. if one needs it,
>>>he can use one of them.
>>>
>>>
>>>
>>>
>>>>versions to *.old if the install of the new one succeeds, and then
>>>>
>>>>
>>>
>>>this breaks the installed software consistency and may screw the package
>>>manager up...
>>>
>>>
>>
>>Sigh, good point, ok, well then at least warn the user about them.
>>
>>
>>>
>>>>prompt for the install location with /sbin as the suggested default.  I
>>>>think that unlike other user installed programs, fsck does not belong in
>>>>/usr/local.  I think Philippe's point that old versions are dangerous is
>>>>quite valid.
>>>>
>>>>
>>>
>>>install to the system default through a system package manager;
>>>
>>>install to the local default from source to not break the system installed
>>>software consistency;
>>>
>>>
>>
>>So the reason for not installing to /sbin is to avoid messing up the
>>package manager?  I regret to say it makes sense.  If that is the
>>reason, then warn the user please about old versions left intact, and
>>suggest they be removed, and prompt the user for the path to install to
>>and remind them to update their $PATH.
>>
> 
> 
> The problem is that some package managers might make reiser4progs a
> "base" package, which removing will emit a loud warning that it might
> break your system.  That said, anyone installing a custom reiser4progs
> may or may not be supposed to have the knowledge to work around it.

Replace "reiser4progs" with "e2fsprogs" and see if it still makes sense.

On my Gentoo system, e2fsprogs is depended on by util-linux, but
reiser4progs isn't depended on by anything, despite the fact that my
root fs is reiser4.  I actually need both -- my /boot is ext3 and my
initrd is ext2.

I see little reason for any of this to change, except maybe to be more
consistent -- either require all FS tools, or force the user to install
the package they need.  Which wouldn't be so bad -- after all, Gentoo
already makes me install the system logger manually, because there are
three possible sysloggers available, so I get a choice at install time.

> It might be easier to make a pseudo-package representing the program

Portage has had this for awhile.  I just add the package name to
/etc/portage/profile/package.provided
and Portage will never install that package as a dependency.

This used to be called "injecting", which actually inserted an empty
package, but now exists in that config file.

> or to actually put
> package building scripts for package-handling distros in the source
> package (or use something like checkinstall, provided it doesn't
> conflict too bad).  [You can also did what Debian did with it's
> 'kernel-package' system; it provides a package specially designed for
> converting a custom kernel into a package,

I think that's overkill, unless Debian really has no way to "provide" or
"inject" a particular package.  Someone who knows how to use
kernel-package can probably also handle package.provide.

The main thing that's nice about kernel-package isn't the
dependency-handling, it's the way it simplifies the process of
installing and managing multiple custom kernels.  For one thing, Debian
manages bootloader config files, generating menu entries and such, and
installing an actual kernel package (custom or otherwise) automatically
copies the kernel image to /boot and updates grub.conf (or whatever)
with an entry named for that kernel version.

I don't see anything that makes a packaged reiser4progs better than an
unpackaged one, except for the two things you're defeating with any
custom version:  dependencies and automatic updates.

Re: need opinions from sysadmins on where reiser4progs should install

[Hubert Chan]

On Tue, 22 Nov 2005 13:33:44 -0600, David Masover <ninja@slaphack.com> said:

> michael chang wrote:

>> or to actually put package building scripts for package-handling
>> distros in the source package (or use something like checkinstall,
>> provided it doesn't conflict too bad).  [You can also did what Debian
>> did with it's 'kernel-package' system; it provides a package
>> specially designed for converting a custom kernel into a package,

> I think that's overkill, unless Debian really has no way to "provide"
> or "inject" a particular package.

Debian has a package called "equivs" that allows you to create dummy
packages.

But it is generally better to just include a debian/ directory in the
sources, and let the Debian package management just handle everything
for you (e.g. upgrading to a new version when Debian includes a newer
version).

Debian generally frowns upon including a debian/ directory in the
upstream sources without any good reason.  But I think that in this
case, there is a good reason.  Just make sure to work with the Debian
maintainer of reiser4progs (Ed Boraas) if you want to do that.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: need opinions from sysadmins on where reiser4progs should install

[Chester R. Hosey]

David Masover wrote:
> 
> I don't see anything that makes a packaged reiser4progs better than an
> unpackaged one, except for the two things you're defeating with any
> custom version:  dependencies and automatic updates.

One big benefit is that installed files are never "lost". It's often
difficult to clean up after a "make install" directly to the target
location. By setting --prefix to a temporary location, building and
installing, then making a tar.gz from the installed files and running
through alien to get a .deb, it's much (much!) easier to remove the
package if I decide to revert to an upstream version, or simply don't
care for the program. It's something like:

./configure --prefix=/tmp/foo && make && make install
cd /tmp/foo
tar czvf ../package.tar.gz *
cd ..
alien package.tar.gz
su (type password)
dpkg -i generated-package-name.deb

A "make install" will often overwrite existing files without asking
first, while a good package manager will warn about conflicts before
trashing old data. Using package management insulates users from having
to know about each file "make install" wants to install. It's let me try
third-party software on one of my Debian machines without worrying about
collateral damage or difficult clean-up afterwards.

That said, I do agree with "make install" defaulting to /usr/local with
a warning that it may not be what the sysadmin wanted. It will warn
those who might not be familiar with convention, while doing what will
be expected by those who are.

Chet