Blocking a base package from installing

Blocking a base package from installing

[Chris Sutcliffe]

I'm using a self compiled vim, so I uninstalled vim-minimal.  Every
time I run setup to get the latest updates, setup attempts to
reinstall vim-minimal - is there a way to make setup ignore
vim-minimal?

Thanks,

Chris

-- 
Chris Sutcliffe

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Hans-Bernhard Bröker]

Am 06.10.2016 um 16:57 schrieb Chris Sutcliffe:
> I'm using a self compiled vim, so I uninstalled vim-minimal.  Every
> time I run setup to get the latest updates, setup attempts to
> reinstall vim-minimal - is there a way to make setup ignore
> vim-minimal?

With the alternative being to pick a fight with the tools, wouldn't it 
be a whole lot more straightforward to install your own vim with 
--prefix $HOME or /usr/local instead?  That's what I do with basically 
all packages I install from sources; and using stow to manage them even 
makes that reasonably painless.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Achim Gratz]

Chris Sutcliffe writes:
> I'm using a self compiled vim, so I uninstalled vim-minimal.  Every
> time I run setup to get the latest updates, setup attempts to
> reinstall vim-minimal - is there a way to make setup ignore
> vim-minimal?

Yes, at least two.

1. Build a proper package and give it a higher version number than
Cygwin's own Vim.  

2. Fake the installation of vim-minimal in /etc/setup/installed.db and
give that fake installation some high version number.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Linda Walsh]

Achim Gratz wrote:
> Chris Sutcliffe writes:
>> I'm using a self compiled vim, so I uninstalled vim-minimal.  Every
>> time I run setup to get the latest updates, setup attempts to
>> reinstall vim-minimal - is there a way to make setup ignore
>> vim-minimal?
> 
> Yes, at least two.
> 
> 1. Build a proper package and give it a higher version number than
> Cygwin's own Vim.  
> 
> 2. Fake the installation of vim-minimal in /etc/setup/installed.db and
> give that fake installation some high version number.
---
Both of which are "lying" to the package manager, to get it to
NOT install an inferior (from the standpoint of not containing
the user-desired modifications/features) package.  It should
be possible to "LOCK" a package (base or not), to prevent it from
being removed/updated/installed or changed by setup, no?  


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 395 bytes --]

On 10/06/2016 01:22 PM, Linda Walsh wrote:
> It should
> be possible to "LOCK" a package (base or not), to prevent it from
> being removed/updated/installed or changed by setup, no? 

Technically possible if someone were to write patches for it to do so.
Are you volunteering?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


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

Re: Blocking a base package from installing

[Andrey Repin]

Greetings, Chris Sutcliffe!

> I'm using a self compiled vim, so I uninstalled vim-minimal.  Every
> time I run setup to get the latest updates, setup attempts to
> reinstall vim-minimal - is there a way to make setup ignore
> vim-minimal?

Install your vim into /usr/local, should be enough for casual use.


-- 
With best regards,
Andrey Repin
Thursday, October 6, 2016 21:32:30

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Achim Gratz]

Linda Walsh writes:
>> 1. Build a proper package and give it a higher version number than
>> Cygwin's own Vim.  
>>
>> 2. Fake the installation of vim-minimal in /etc/setup/installed.db and
>> give that fake installation some high version number.
> ---
> Both of which are "lying" to the package manager, to get it to
> NOT install an inferior (from the standpoint of not containing
> the user-desired modifications/features) package.  It should
> be possible to "LOCK" a package (base or not), to prevent it from
> being removed/updated/installed or changed by setup, no?  

Not really, although there is some skipping of intermediate steps
involved.  By building your own package you introduce a second package
source (like Cygport does).  The two package sources can only coexist if
either the package versions are all different (note: version here
includes the "build number") or the package sets are disjunct and
dependencies are only present from the "second source" into the first.
If you were to change the packaging of an existing package in the base
package source, you'd have to provide obsolescence packages for those
packages you no longer provide content for.  The two suggestions just
produce the end result of doing that with different amounts of not
actually doing all the work that would be required (and if you break
your system you get to keep the pieces).

Now, that last question of yours: No, the package manager should never
allow you to not install a base package.  These are in category "Base"
precisely so the rest of the system can rely on the functionality
provided.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Linda Walsh]

Achim Gratz wrote:
> Now, that last question of yours: No, the package manager should never
> allow you to not install a base package.  These are in category "Base"
> precisely so the rest of the system can rely on the functionality
> provided.
---
	And what other programs will stop functioning if 
vim is not installed?

	If I compile and install a version of vim on my system, 
why would I want to put it in a location like /usr/local where
it might not be used -- all the time?  

	I'm the only user on my system -- whether I run as a user
or as root, or whatever, I'm not doing this for someone else.  If I
try to edit a file using 'vim' from the explorer menu, will it invoke
my vim in /usr/local -- of course not.  Installing some private
copy where all the rest of the system will ignore it, is asking
for headaches.  

	How many people do you think are installing cygwin on 
servers to be used by many people, vs. their personal machines to only
be used by them?

	But back to the 1st Q.  What other programs will fail to work
if the base-version of vim isn't installed?





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Andrey Repin]

Greetings, Linda Walsh!

> Achim Gratz wrote:
>> Now, that last question of yours: No, the package manager should never
>> allow you to not install a base package.  These are in category "Base"
>> precisely so the rest of the system can rely on the functionality
>> provided.
[snip]
>         But back to the 1st Q.  What other programs will fail to work
> if the base-version of vim isn't installed?

The question is not about vim, the question is about base category in general.
It's vim only now, tomorrow it'll be something else. You have to stop and draw
the line somewhere, if you, as a package maintainer, want a predictable
behavior for all future installations.


-- 
With best regards,
Andrey Repin
Friday, October 7, 2016 13:28:54

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Hans-Bernhard Bröker]

Am 07.10.2016 um 02:07 schrieb Linda Walsh:
> Achim Gratz wrote:
>> Now, that last question of yours: No, the package manager should never
>> allow you to not install a base package.  These are in category "Base"
>> precisely so the rest of the system can rely on the functionality
>> provided.
> ---
>     And what other programs will stop functioning if vim is not installed?

Vi is, for better or for worse, the default/fall-back system editor.  It 
is assumed to be there by every useful definition of what "Unix" is. 
The possibilities for things breaking if it's not there are therefore 
almost endless.

>     If I compile and install a version of vim on my system, why would I
> want to put it in a location like /usr/local where
> it might not be used -- all the time?

Because /usr/local is the designated location for software that's not 
part of the organized software distribution.  If you want to build your 
own, /usr/local is where it's supposed to go --- or $HOME if you don't 
have admin privileges.

Unix does have a very different approach to installing programs compared 
to Windows, in that it collects files from various packages in a few 
central places: /usr/bin, /usr/etc, /etc, and so on.  That approach 
requires consistent organization to avoid complete chaos.  Distributions 
like Cygwin provide that organization.  You mess with that at your own 
peril.  That's why non-distribution software gets its own area to work 
in: /usr/local.

>     I'm the only user on my system -- whether I run as a user
> or as root, or whatever, I'm not doing this for someone else.

Did it occur to you that the system really has to support much more 
varied use cases than your own particular corner case?

> If I try to edit a file using 'vim' from the explorer menu, will it
> invoke my vim in /usr/local -- of course not.

If you do set up such an explorer menu entry, it'll do whatever you tell 
it to.  It'll only end up "of course not" working if you "of course" 
configure things differently than you actually wanted to.  But why would 
anyone do that?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

intelligent following of directions, or following them by rote...

[Linda Walsh]

Andrey Repin wrote:
> Greetings, Linda Walsh!
> 
>> Achim Gratz wrote:
>>> Now, that last question of yours: No, the package manager should never
>>> allow you to not install a base package.  These are in category "Base"
>>> precisely so the rest of the system can rely on the functionality
>>> provided.
> [snip]
>>         But back to the 1st Q.  What other programs will fail to work
>> if the base-version of vim isn't installed?
> 
> The question is not about vim...
---
	But it is about vim.  That's the package the user wanted to
install their own version of.

	There is such a thing of not following rules, guidelines and 
instructions without thinking about the situation.

	If you follow things without thinking, you'll often end up
screwing yourself in the long run.

	How many installer packages tell you to accept their "default"
(always says "recommended") vs. choosing specifics?  The defaults often
contain items you don't want while not providing things you do.  The
default for Nvidia drivers is to install 3D-drivers even if you don't
have a 3D screen and goggles.  What's intelligent about that?

> It's vim only now, tomorrow it'll be something else.
---
	Right, Today, it's taking a walk by the seashore, tomorrow
it's jumping off a cliff.  Um.. no!  If you do some research and/or know
a bit about what you are doing, you can stop before you jump off the cliff.

> You have to stop and draw
> the line somewhere, if you, as a package maintainer, want a predictable
> behavior for all future installations.
---
	But you can't get predictable behavior now.  It's running
on windows (1st problem), 2nd, it doesn't follow MS-Win conventions.
3rd, Windows sends out incompatibility patches on a regular basis.
Documented features in windows are ignored and overwritten in cygwin --
so you already have unpredictability.  I haven't installed any updates
to my system since the new user-auth/password stuff was added in because
the stuff I have works now with a NT4 type samba domain controller.  Above
that is NT5 w/active directory -- installing LDAP and losing _easy_
control over what I already have (enough research and struggle and I might
get it back, but I have other things to do that have higher priority. 

	As for package maintainers needing some specific behavior --
if a backdoor to your system was part of the "base" system, would you
stick to your "line" and install it?  If you say "no", then you are 
using your brain and not doing it by rote.  If you can do it, why shouldn't
other people be able to do it on their system(s)?  

	Another simple example -- where does one install cygwin?  In
the /cygwin dir (Windows says not to do that -- it wants programs
in "program files" or "program files (x86)).  Who do you follow?
How about whether you install it in /cygwin or in "/" so files @
/etc will be in \etc on windows?  Cygwin recommends installing it
in /cygwin, but at one point (don't know about now), most of the devs
admitted that they installed it in "/" for their personal use.  

	Anyway, thinking about what you are doing and why things are
they way they are, is important -- which is why I asked, what affect
on the cygwin installation would be if you didn't install the base
vim package?  If you don't know the answer, then maybe the defaults
are for you, but if you have an idea of what vim does and how it might
be used to run the rest of cygwin, then you might experiment to find
if things fail or continue to work w/o the base-vim.  Just a thought.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Blocking a base package from installing

[Linda Walsh]

Hans-Bernhard Bröker wrote:



> If you do set up such an explorer menu entry, it'll do whatever you tell 
> it to. 
---
	There is already such an addon for vim -- and it launches
it from the system-standard location.

	Putting a copy in /usr/local won't be called.  If you want to
replace the main copy and all it's purposes/uses, you need to overwrite
the system copy.  

> It'll only end up "of course not" working if you "of course" 
> configure things differently than you actually wanted to.  But why would 
> anyone do that?
---
	Why would you install a system copy of vim anywhere other 
than in the system location?  To install it in /usr/local would 
prevent it from working normally -- why would anyone do that?

> Did it occur to you that the system really has to support much
> more varied use cases than your own particular corner case? 
---
	Not on my system.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: intelligent following of directions, or following them by rote...

[Brian Inglis]

On 2016-10-07 16:04, Linda Walsh wrote:
> Andrey Repin wrote:
>> Greetings, Linda Walsh!
>>> Achim Gratz wrote:
>>>> Now, that last question of yours: No, the package manager should never
>>>> allow you to not install a base package.  These are in category "Base"
>>>> precisely so the rest of the system can rely on the functionality
>>>> provided.
>>>         But back to the 1st Q.  What other programs will fail to work
>>> if the base-version of vim isn't installed?
>> The question is not about vim...
>     But it is about vim.  That's the package the user wanted to
> install their own version of.
>     Anyway, thinking about what you are doing and why things are
> they way they are, is important -- which is why I asked, what affect
> on the cygwin installation would be if you didn't install the base
> vim package?  If you don't know the answer, then maybe the defaults
> are for you, but if you have an idea of what vim does and how it might
> be used to run the rest of cygwin, then you might experiment to find
> if things fail or continue to work w/o the base-vim.  Just a thought.

Type v inside a PAGER (e.g. less or more).
Run an editor on the current (long) command line in readline or shell history.
Edit a commit message in any VCS.
Edit crontab entries.
You can change some of these if you prefer ed or emacs (EDITOR, VISUAL),
and ex is a symlink to vi (vim-minimal).

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: intelligent following of directions, or following them by rote...

[Erik Soderquist]

On Fri, Oct 7, 2016 at 6:04 PM, Linda Walsh wrote:
>         As for package maintainers needing some specific behavior --
> if a backdoor to your system was part of the "base" system, would you

If there is a "back door" in a base package, that is a security
failing and needs to be reported and fixed

-- Erik

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: intelligent following of directions, or following them by rote...

[Linda Walsh]

Brian Inglis wrote:
> On 2016-10-07 16:04, Linda Walsh wrote:
>>     ... what affect
>> on the cygwin installation would be if you didn't install the base
>> vim package?    Just a thought.
> 
> Type v inside a PAGER (e.g. less or more).
> Run an editor on the current (long) command line in readline or shell 
> history.
> Edit a commit message in any VCS.
> Edit crontab entries.
> You can change some of these if you prefer ed or emacs (EDITOR, VISUAL),
> and ex is a symlink to vi (vim-minimal).
---
	Good point -- but none of those should cease to run if you are
putting your own "well working" version of vim it its place -- which
was where this got started in someone desiring to put their own version
on their machine.

	FWIW, I've run my own compiled Gvim version on linux for years
and had fewer problems.  My linux distro supplies a version that links
with various languages (ruby, python, perl, etc) -- but they don't
use run-time dynamic loading, so if something happens and the versions
don't match (they must match, even, the patch-levels) then neither vim
nor gvim can be used as an editor.  Such was sufficient reason for me
to build and replace the OS-instance of vim/gvim.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: intelligent following of directions, or following them by rote...

[Linda Walsh]

Erik Soderquist wrote:
> On Fri, Oct 7, 2016 at 6:04 PM, Linda Walsh wrote:
>>         As for package maintainers needing some specific behavior --
>> if a backdoor to your system was part of the "base" system, would you
> 
> If there is a "back door" in a base package, that is a security
> failing and needs to be reported and fixed
---
	I think you miss the point -- the point would be whether or
not you believe you "need" to install and use it "as is", or if consider
that maybe you want a different, "fixed" version?  Whether you fix it 
or someone else does often depends on turn-around time and ease of 
user building, but I think you answer the question -- you'd
take action to replace the code *rather* than living with it.

	Hey, I never accused, directly or obliquely, you of not using
your head...  ;-)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple