Re: /usr/local/bin in $PATH in system scripts?

2007-05-10 Thread Micah Cowan
Ming Hua wrote:
> On Thu, May 10, 2007 at 08:33:41PM -0700, Micah Cowan wrote:
>> Ming Hua wrote:
>>> For the sake of discussion, I think
>>>
>>> #!/usr/bin/env perl
>>>
>>> will pick up $PATH and is a valid #! line.  I also believe this is widely
>>> used.
>> Yes, it will. But isn't that a somewhat silly suggestion considering the
>> context? If /usr/bin/perl were "bad" then /usr/bin/env would be just as
>> "bad", it seems to me...
> 
> That's not the point.
> 
> Fergal's argument is, if you think scripts honoring the $PATH variable
> and use the binaries /usr/local/bin/ is a feature because it respects
> the user preference, you should also think using "#!/usr/bin/env perl"
> instead of "#!/usr/bin/perl" a feature as well, for the same reason.
> And I think it's a valid argument.

But why should it apply to perl and not to env? What if you have a
broken env in /usr/local/bin?

I actually thing that /usr/bin/env is probably preferable, though: but
/usr/bin/perl has too strong a tradition behind it. I have noticed that
a decent number of python programmers do it that way.

I actually see both sides of the argument. Perhaps there should be a
single location for a base "restricted path" to be stored, and
modifications would be made from that, if necessary. I would probably
agree that /usr/local/bin shouldn't be in there by default.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: /usr/local/bin in $PATH in system scripts?

2007-05-10 Thread Ming Hua
On Thu, May 10, 2007 at 08:33:41PM -0700, Micah Cowan wrote:
> Ming Hua wrote:
> > 
> > For the sake of discussion, I think
> > 
> > #!/usr/bin/env perl
> > 
> > will pick up $PATH and is a valid #! line.  I also believe this is widely
> > used.
> 
> Yes, it will. But isn't that a somewhat silly suggestion considering the
> context? If /usr/bin/perl were "bad" then /usr/bin/env would be just as
> "bad", it seems to me...

That's not the point.

Fergal's argument is, if you think scripts honoring the $PATH variable
and use the binaries /usr/local/bin/ is a feature because it respects
the user preference, you should also think using "#!/usr/bin/env perl"
instead of "#!/usr/bin/perl" a feature as well, for the same reason.
And I think it's a valid argument.

Debian guarantees /usr/bin/perl and /usr/bin/env will work.  I think the
focus of this discussion is what happens if we have a "bad"
/usr/local/bin/perl, not a "bad" /usr/bin/perl.

Ming
2007.05.10

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: /usr/local/bin in $PATH in system scripts?

2007-05-10 Thread Micah Cowan
Ming Hua wrote:
> On Thu, May 10, 2007 at 08:59:19AM -0700, Micah Cowan wrote:
>> Fergal Daly wrote:
>>
>>> You are also implying that everything in /usr/bin that start with
>>>
>>> #! /usr/bin/{perl,python,...}
>>>
>>> is wrong and should actually start with
>>>
>>> #! {perl,python,...}
>> That doesn't work. #! requires a path.
> 
> For the sake of discussion, I think
> 
> #!/usr/bin/env perl
> 
> will pick up $PATH and is a valid #! line.  I also believe this is widely
> used.

Yes, it will. But isn't that a somewhat silly suggestion considering the
context? If /usr/bin/perl were "bad" then /usr/bin/env would be just as
"bad", it seems to me...

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: /usr/local/bin in $PATH in system scripts?

2007-05-10 Thread Ming Hua
On Thu, May 10, 2007 at 08:59:19AM -0700, Micah Cowan wrote:
> Fergal Daly wrote:
> 
> > You are also implying that everything in /usr/bin that start with
> > 
> > #! /usr/bin/{perl,python,...}
> > 
> > is wrong and should actually start with
> > 
> > #! {perl,python,...}
> 
> That doesn't work. #! requires a path.

For the sake of discussion, I think

#!/usr/bin/env perl

will pick up $PATH and is a valid #! line.  I also believe this is widely
used.

Ming
2007.05.10

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


What to do in case of power down while updating/upgrading from site or from a CD

2007-05-10 Thread shirish

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,
  Its partly a question & partly an idea. Sorry if its a repost.The way
I look at it when we update, upgrade either from CD or on-line
if the power goes down is there some sane way so that the it starts the next
part of doing things when you boot up
the next time. Also are there some/any  way/procedure to make it so that it
updates something in sessions,  say
100 MB over 6 sessions rather than doing the whole upgrade in one go.
 The use case is pretty simple, you have a user shirish, who lives in
developing world where when the
mains will fail is no idea & his UPS only gives 5 minutes as backup time.
Now in such situation what is he
supposed to do other than try his luck?
  For e.g. just like we do when we update with Gusty, each day there
are  10-15 packages & that hardly takes
to update. Something similar so its sees no. of packages to update decided
by user. Comments, suggestions,
flames all welcome.
- --
 Shirish Agarwal
 This email is licensed under
http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFGQ2qwlQ1T+3KaixcRAuUvAKCSuyyJzT5/KNO5e7Fjb6Hhu+tFwgCeNP00
IcFUNcI/ng3Kbp7AnCeTgDM=
=YfSv
-END PGP SIGNATURE-
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: /usr/local/bin in $PATH in system scripts?

2007-05-10 Thread Fergal Daly
On 10/05/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> Fergal Daly wrote:
> > On 10/05/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> >> On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
> >>> Sorry, I have no idea what ubuntu policy is.   But good defensive
> >>> scripting practice includes setting your $PATH to something safe.  A
> >>> good script should always not trust the environment it was handed along
> >>> with many other things that people don't always do.
> >> I have to disagree.  The environment is precisely the tool available to 
> >> users to
> >> change the behavior of your script externally.  It's not nice to stomp on 
> >> user
> >> preferences.
> >>
> >> The original problem is user error.  Installing an upgraded perl in 
> >> /usr/local
> >> without installing all of the needed perl libraries or removing 
> >> /usr/local/bin
> >> from the default system PATH is incorrect usage.  Don't break features to 
> >> avoid
> >> user error, please.
> >
> > You have 2 assertions in one sentence, I'm splitting them up.
> >
> > 1 - "Installing an upgraded perl in /usr/local without installing all
> > of the needed perl libraries is incorrect usage"
> >
> > This directly contradicts the debian policy I quoted which essentially
> > says that the contents of /usr/local should have no impact on whether
> > your system works or not. I know Debian is not Ubuntu but in the
> > absence of Ubuntu policy docs, I'm assuming that the Debian policy is
> > a sane starting point.
>
> Yes, but that's not actually what it states (repasted):
> > "However, because /usr/local and its contents are for exclusive use of
> > the local administrator, a package must not rely on the presence or
> > absence of files or directories in /usr/local for normal operation."
>
> It is not relying on the presence or absence of any files. It is relying
> on your PATH to give it a good perl. That /perl/ is relying on the
> presence or absence of various files. I don't think that this paragraph
> was ever meant to be applied to such indirect reliance.

It's relying on the absence of perl or if perl is there it's relying
on the presence of /usr/local/lib/perl/Foo/Bar.pm . Also, it's not
_my_ PATH, it's the path that is explicitly set by some system
scripts.

Can you give me a definition of "good perl" that isn't equivalent to
"exactly compatible with /usr/bin/perl"? Where "compatible" means
feature for feature _and_ bug for bug because I as a sysadmin have no
idea what the next apt-get upgrade will depend on.

If /usr/local/bin/X has to be exactly the same as /usr/bin/X, what's the point?

Please also address how I'm supposed to keep the modules in this
version of perl in sync with the versions in /usr/lib without help
from apt (I'm not saying it can't be done but your interpretation
imposes this extra work on me). How about when I install a package
that pulls in a new perl-Blah.deb as a dependency? I should manually
track and replicate these changes?

A far more useful interpretation is "the contents /usr/local should
have no effect on the system's normal operation". What are the
down-sides of this interpretation?

> > You are also implying that everything in /usr/bin that start with
> >
> > #! /usr/bin/{perl,python,...}
> >
> > is wrong and should actually start with
> >
> > #! {perl,python,...}
>
> That doesn't work. #! requires a path.

Sorry

#! /usr/bin/env {perl,python,...}

The point being that if you believe that all system scripts should
respect each user's path then you should be appalled at the number of
things in /usr/bin/ that completely ignore it,

F

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: /usr/local/bin in $PATH in system scripts?

2007-05-10 Thread Micah Cowan
Fergal Daly wrote:
> On 10/05/07, Forest Bond <[EMAIL PROTECTED]> wrote:
>> On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
>>> Sorry, I have no idea what ubuntu policy is.   But good defensive
>>> scripting practice includes setting your $PATH to something safe.  A
>>> good script should always not trust the environment it was handed along
>>> with many other things that people don't always do.
>> I have to disagree.  The environment is precisely the tool available to 
>> users to
>> change the behavior of your script externally.  It's not nice to stomp on 
>> user
>> preferences.
>>
>> The original problem is user error.  Installing an upgraded perl in 
>> /usr/local
>> without installing all of the needed perl libraries or removing 
>> /usr/local/bin
>> from the default system PATH is incorrect usage.  Don't break features to 
>> avoid
>> user error, please.
> 
> You have 2 assertions in one sentence, I'm splitting them up.
> 
> 1 - "Installing an upgraded perl in /usr/local without installing all
> of the needed perl libraries is incorrect usage"
> 
> This directly contradicts the debian policy I quoted which essentially
> says that the contents of /usr/local should have no impact on whether
> your system works or not. I know Debian is not Ubuntu but in the
> absence of Ubuntu policy docs, I'm assuming that the Debian policy is
> a sane starting point.

Yes, but that's not actually what it states (repasted):
> "However, because /usr/local and its contents are for exclusive use of
> the local administrator, a package must not rely on the presence or
> absence of files or directories in /usr/local for normal operation."

It is not relying on the presence or absence of any files. It is relying
on your PATH to give it a good perl. That /perl/ is relying on the
presence or absence of various files. I don't think that this paragraph
was ever meant to be applied to such indirect reliance.

> You are also implying that everything in /usr/bin that start with
> 
> #! /usr/bin/{perl,python,...}
> 
> is wrong and should actually start with
> 
> #! {perl,python,...}

That doesn't work. #! requires a path.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: KLF setup

2007-05-10 Thread George Farris
On Thu, 2007-10-05 at 19:07 +1200, Matthew Paul Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On May 10, 2007, at 3:01 AM, George Farris wrote:
> > ...
> > Couldn't agree more, however, in the interim if there was some concise
> > docs for Feisty it would be great.  Maybe we could get something going
> > here to solve the problem until the GUI wizards are in.  Possibly an
> > Ubuntu Server docs url on ubuntu.com.  Fill it with some howto
> > information covering Samba, LDAP, Kerberos, NFSv4, Active Directory
> > Integration.
> > ...
> 
> If you can write some, that would be great! Please do so at
> .

I would love to do this but I do not have access to Active Directory and
I'm also one of the people that look at the docs that are out there and
say, hmmm ok which one do I follow, which way should I do this?

If I can have access to a mentor for some of this then that might help.




-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: /usr/local/bin in $PATH in system scripts?

2007-05-10 Thread Fergal Daly
On 10/05/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
> > Sorry, I have no idea what ubuntu policy is.   But good defensive
> > scripting practice includes setting your $PATH to something safe.  A
> > good script should always not trust the environment it was handed along
> > with many other things that people don't always do.
>
> I have to disagree.  The environment is precisely the tool available to users 
> to
> change the behavior of your script externally.  It's not nice to stomp on user
> preferences.
>
> The original problem is user error.  Installing an upgraded perl in /usr/local
> without installing all of the needed perl libraries or removing /usr/local/bin
> from the default system PATH is incorrect usage.  Don't break features to 
> avoid
> user error, please.

You have 2 assertions in one sentence, I'm splitting them up.

1 - "Installing an upgraded perl in /usr/local without installing all
of the needed perl libraries is incorrect usage"

This directly contradicts the debian policy I quoted which essentially
says that the contents of /usr/local should have no impact on whether
your system works or not. I know Debian is not Ubuntu but in the
absence of Ubuntu policy docs, I'm assuming that the Debian policy is
a sane starting point.

What you are basically saying is that whenever I install _anything_
into /usr/local/bin I should carefully check that no system scripts
will be upset by this. I also need to check that no system scripts in
the _future_ will be upset by this!

Also, if I install my own perl in /usr/local/bin, I must install all
the libraries used by any other package that might be installed by
Ubuntu but I must do this by hand because apt will only manage the
dependencies of my /usr/bin/perl .

This basically makes it impractical to put anything into /usr/local/bin.

You are also implying that everything in /usr/bin that start with

#! /usr/bin/{perl,python,...}

is wrong and should actually start with

#! {perl,python,...}

in order to pick up whatever version of {perl,python,...} the user prefers.

In summary, you are saying that anything I put in /usr/local/bin
should be such that I could safely put it into /usr/bin. So what's the
point of /usr/local?

2 - "Installing an upgraded perl in /usr/local without removing
/usr/local/bin from the default system PATH is incorrect usage"

Users should not have to modify 20 scripts in /etc/ just because
they've put something in /usr/local/bin,

F

> -Forest
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGQxgHRO4fQQdv5AwRAihpAJ9Xt+Taa2NQLDPwp6q/1Ieo1zgVgwCgiuAL
> tt0Y02QX+zHj7Bvuw/9wcNA=
> =qnXL
> -END PGP SIGNATURE-
>
>

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: /usr/local/bin in $PATH in system scripts?

2007-05-10 Thread Forest Bond
On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
> Sorry, I have no idea what ubuntu policy is.   But good defensive
> scripting practice includes setting your $PATH to something safe.  A
> good script should always not trust the environment it was handed along
> with many other things that people don't always do.

I have to disagree.  The environment is precisely the tool available to users to
change the behavior of your script externally.  It's not nice to stomp on user
preferences.

The original problem is user error.  Installing an upgraded perl in /usr/local
without installing all of the needed perl libraries or removing /usr/local/bin
from the default system PATH is incorrect usage.  Don't break features to avoid
user error, please.

-Forest


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: KLF setup

2007-05-10 Thread Matthew Paul Thomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 10, 2007, at 3:01 AM, George Farris wrote:
> ...
> Couldn't agree more, however, in the interim if there was some concise
> docs for Feisty it would be great.  Maybe we could get something going
> here to solve the problem until the GUI wizards are in.  Possibly an
> Ubuntu Server docs url on ubuntu.com.  Fill it with some howto
> information covering Samba, LDAP, Kerberos, NFSv4, Active Directory
> Integration.
> ...

If you can write some, that would be great! Please do so at
.

Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFGQsSu6PUxNfU6ecoRAnmMAJ9Q5n8hmvDCkbdWfTP4t2aaAfnTNACgo/PC
H9OaE8sca+qW69sX4dgnbWg=
=dvy4
-END PGP SIGNATURE-


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss