Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 3 April 2017 at 09:01, Pierre-Yves Chibon  wrote:

> Just a note that the email you are replying to wasn't send to the list.
> Such
> wording is not welcome on this list and does not reflect how we want the
> fedora
> devel list to be.
>

I know.
As you probably noticed I'm trying to not reply to such comments but this
one I found as kind good opportunity to tell something about m past and my
motivation.

Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Pierre-Yves Chibon]

On Sun, Apr 02, 2017 at 08:49:18PM +0100, Tomasz Kłoczko wrote:
>On 2 April 2017 at 16:25, Reindl Harald  wrote:
> 
>  funny that one assumes you can enter "fedora FPC" in a search engine
>  after playing smart-ass in so many mails and it's your namend
>  responisiblity to inform yourself about the distribution *before* you
>  write hundrets of completly unqualified and uneducated mails about a
>  parallel universe wher you have done so much things without namimg the
>  distribution and the reasons why you are no longer there
> 
>I really don't like when someone during discussion when I'm tryin bring as
>much facts as I can or tests (or similar things used in civilised
>discussion), and someone is not able to to respond on similar level is
>turning conversation (because it is no longer discussion) to "ad personam"
>reply.

Just a note that the email you are replying to wasn't send to the list. Such
wording is not welcome on this list and does not reflect how we want the fedora
devel list to be.

Sorry about this.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Pierre-Yves Chibon]

On Sun, Apr 02, 2017 at 09:25:55PM +0100, Tomasz Kłoczko wrote:
>On 2 April 2017 at 17:06, Jens Lody  wrote:
> 
>  Fedora Packaging Committee:
>  https://fedoraproject.org/wiki/Packaging_Committee?rd=FPC
> 
>Just humle question: why I should contact FPC about two bugs which I found
>in dnf? Comment about contacting FPC was straight under my comment about
>these bugs.
>This committee seems has nothing to do with dnf development.
>And/or as long as no one still confirmed that what I see in result of my
>test unit is real still I have nothing to submit about change anything in
>current packaging methodology.
>Sorry but I'm a bit confused now :-L

This committee is what controls what is and what isn't part of the Fedora
Packaging Guidelines.
So while dnf bugs should be reported on bugzilla, any changes at the policy
level should go through the Fedora Package Committee.
With the understanding that under the current FPG what you are presenting as a
bug in dnf might not be considered as such by the dnf developers, thus potential
need to go to the FPC to get the FPG changed.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 2 April 2017 at 17:06, Jens Lody  wrote:

> Fedora Packaging Committee:
> https://fedoraproject.org/wiki/Packaging_Committee?rd=FPC
>

Just humle question: why I should contact FPC about two bugs which I found
in dnf? Comment about contacting FPC was straight under my comment about
these bugs.
This committee seems has nothing to do with dnf development.
And/or as long as no one still confirmed that what I see in result of my
test unit is real still I have nothing to submit about change anything in
current packaging methodology.

Sorry but I'm a bit confused now :-L

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 2 April 2017 at 16:25, Reindl Harald  wrote:

> funny that one assumes you can enter "fedora FPC" in a search engine after
> playing smart-ass in so many mails and it's your namend responisiblity to
> inform yourself about the distribution *before* you write hundrets of
> completly unqualified and uneducated mails about a parallel universe wher
> you have done so much things without namimg the distribution and the
> reasons why you are no longer there
>

I really don't like when someone during discussion when I'm tryin bring as
much facts as I can or tests (or similar things used in civilised
discussion), and someone is not able to to respond on similar level is
turning conversation (because it is no longer discussion) to "ad personam"
reply.
If you really think that only link to "the paralel universe" may convince
you to a least *one time* execute test which I've posted .. OK, here is you
link:

ftp://ftp.icm.edu.pl/pub/linux/dist/pld/dists/ra/PLD/SRPMS/SRPMS/

Please have look on timestamps and specs files inside those src.rpm
packages. You can find a bit more in subdirectories above this path.

Reason why there is no longer this distribution around is because I was
young and I've not spotted that few people leaving in different city
started thinking about monetising results of our work. After those people
took over DNS it was few weeks dirty fight which I'm not proud.
In other words I was immature that doing +50% of whole work within about
100 strong people group I've did not secured my IPs and someone been
thinking that I was so psychologically depend on what I've been doing for
few years in my free time that after this "coup" I'll accept "new command"
or will act like nothing happened. It was hard lesson but such thing
sometimes happens ..

Second distribution in which you can find traces of mine earliest activity
is .. installed on your computer.
Just try to execute "rpm -qa --changelog | grep kloczek".
[mode=joking]
I'm not sure where you are now and maybe it will be not possible to
establish connectivity to this "parallel universe" ;-) but what is on your
computer probably is not out-of-this-world. And no .. I've not just hacked
your computer :-P
[/mode]
About 15 years ago it was much more such traces (something like 30-50 times
more) but after in most of the RH packages %changelog tails entries have
been cut only few remained.
If you are really interested what more I've done only in rpm context ..
If you are using mc (if not "dnf install -y mc; mc") after executing this
program enter "cd rpms://", press enter, then wait few seconds, or try to
press enter on any source or binary package which you have. Yes, I wrote
about 80% of rpm mc support. You can check how useful it is by "cd
" link. After pressing enter on any src.rpm go inside
then press F3 on any spec file.
If you will have look on those spec with tabbed indentation or using exact
order fields in spec file you probably will find that such style is shared
still by more or less biggest part the current Fedora specs files. Try to
think who published first time some critical mass of spec files +20 years
ago that this style still is possible to find in so many spec files. It was
in RHCN time where I've published something like +100 (but not more than
300 in total with different versions) src.rpm packages.
Just realised that I've never told about all those details together. So far
observing how many people are still sharing the same aesthetics used in
specs which I've never touched was enough for me ..
BTW style of writing spec files. In rpm-4.0.2-102.src.rpm on this
 link you can find how easy was possible to write awk
script (adapter.awk) which been used to indenting 100% of all those spec
files. I did not wrote this script (I've added only some number of
improvements). Using the samy style was necessary to have to control
thousands specs files using very limited human resources. IMO such common
indentation is even more important today in case of Fedora because between
thousands package maintainers still it is only handful of very skilled
people or mentors with enough time able to audit other people work on
massive scale. On big scale no one is analysing spec files line by line but
by trying to find any "broken patterns" around which usually other
packagers adding some "strange" lines.
This few KB awk script gave us much more that for example rpmlint.

I know that how I'm expressing myself may look a bit arrogant, rude or even
disrespectful. However strongness of my words comes only from what *I've
really done or able to prove*  even if someone is thinking that in giving
pure bollocks/BS. I'm trying to control this part "me" but it is really
hard to change some deeply anchored habits related to how I'm behaving when
it is not about to have opinion or guess.
If you will give me enough time I would be able to share straight much more
of what I've done, or which have been done by some other people which I've
only 

Re: Mass issue: /usr/bin/env dependency

[Jens Lody]

Am Sun, 2 Apr 2017 13:23:25 +0100
schrieb Tomasz Kłoczko :

> On 2 April 2017 at 12:20, Igor Gnatenko
>  wrote:
> 
> > All your points here are basically going to /dev/null if you are not
> > going to contact FPC
> >  
> 
> Funny .. seems you assuming that I know what FPC stands fr.
> 
> kloczek


Fedora Packaging Committee:
https://fedoraproject.org/wiki/Packaging_Committee?rd=FPC

Jens


pgpysrbymlzEG.pgp
Description: Digitale Signatur von OpenPGP
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 2 April 2017 at 12:20, Igor Gnatenko 
wrote:

> All your points here are basically going to /dev/null if you are not
> going to contact FPC
>

Funny .. seems you assuming that I know what FPC stands fr.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unversioned Obsoletes (was Re: Mass issue: /usr/bin/env dependency)

[Nico Kadel-Garcia]

On Fri, Mar 31, 2017 at 5:02 PM, Fernando Nasser  wrote:
> On 2017-03-31 4:04 PM, Michael Schwendt wrote:
>>
>> On Fri, 31 Mar 2017 15:16:22 -0400, Fernando Nasser wrote:
>>
>>> A few issues I remember caused by unversioned Obsoletes (before they
>>> were banished to Hell) were:
>>>
>>> - Not being able, ever again, to provide the thing being obsoleted.  And
>>> believe me, things change ;-)
>>>
>>> - The Obsoletes affects other channels as well, not only the content of
>>> the channel that contains the package that contains the Obsoletes is
>>> affected.\
>>> If the obsoleted name is needed by something in some other package even
>>> being at a higher version it cannot be installed.
>>>
>>> So for a decade or more (I list track, I am here for almost 2 decades),
>>> the Obsoletes always comes with a '=' or a '<='.
>>
>> RPM itself also blocks a package from being installed, if *any* other
>> installed packages obsoletes that package name. If non-versioned, you're
>> doomed and would need to get rid of the Obsoletes tag first.
>>
>> An overly simplified test-case where the package containing the Obsoletes
>> tag is replaced directly via rpm -Uvh is not sufficient.
>
>
> One has to resort to triggers, and even that does not work in all cases.
>
> Wretched thing, unversioned Obsoletes.
>
> Fernando

We Hates It(tm).

Pretty much this happened with ecj when its name changed between
Fedora eleases, with gcc being published as "gcc" for version 3 and
"gcc4" for version 4 and changed to "gcc" for version 4, with the
openssl compatibility libraries, and when when default Python major
versions change.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2017-04-02 at 07:55 +0100, Tomasz Kłoczko wrote:
> On 1 April 2017 at 22:25, Neal Gompa  wrote:
> 
> > This is a libsolv test case. Fedora's high level package manager
> > (DNF[0]) uses libsolv[1] for its resolver engine. If you're trying
> > to
> > determine how something is going to behave, you can write a test
> > case
> > and use testsolv (in the libsolv-tools package) to run the test
> > case
> > and see what the solver would do. It gives you the ability to
> > reproducibly replay any kind of solution scenario. DNF will output
> > libsolv test cases for a given action when "--debugsolver" is added
> > as an option to the command.
> > 
> 
> And from your prev Igor email:
> 
> And please, stop spreading misinformation! As I said earlier, you
> have
> > to prove your information to FPC (which implies confirmation from
> > DNF
> > developers).
> 
> 
> So .. looks like:
> 1) your test case does not test what I've been testing (did you
> really
> download, try and look at it?).
> 2) Igor as well seems not been trying to test anything.
I showed you testcase where if you don't use versioned obsoletes, you
can't re-introduce back original package.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljg3yoACgkQaVcUvRu8
X0ydLw/8DvpsEIGzm0jzK49OlqX3ELzLEHIsEUm96l49QSBbKcrLxSNx1vP+jn6B
wfl7YS4JvglU83yrmcZYlQRqEhpbclRxqOYhYvQ5/MjOqVlnjD2yXbARKNoIoFoa
YeWaTkm4JLtxP4aLyxQHq7ccHiNKhm1+RMQaQRYS6gBDI6JMs5YCXM3sMyeKl5NP
dxBZfBUDTYNnh3PA4jvWcgAQTnv5Qmd9dCqMT72f+nSebsOqn1dBwQsL/bgTNkp1
idCorJbBDhGGUxpvS4egxDLjfSyoZl7bfhUhU1WBaLMHyL2oye7r5eCclr6b3I75
C3Ytp+8/r75meidSzmfSyxeXCXCQiZWfAqraYkLcVpB9QGFKy4gaMbe4BPXGZEUB
hU4YAqQKKWeMg9xw+X/6m7jDdYq5pAWOOJ2V1iXSN+lj3/k3HoG6OBFQnddBAX2d
uRCa3annCKzVBnZlRA53HH5yaNYMG9DkkucQTIAPRAk9dKe/SpKZJLHmXvygrGJf
f5OgaLmfzgNXXEu4RqQWjfeKhPfY/z/DQpcgQvNO05yvEzAkNHKp1QMO77LiNtQ0
UaYcYVmBRzZvh5USYtfkop6He1/muO80O/OmmBBY1flrHXnIKpUR0/z8rBoM32VP
sG0bbLGSMbxdgV8zuTPqiiYrMrJ9JkzKwgJN/OEzh4wCHomAIq8=
=4h9b
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2017-04-02 at 07:55 +0100, Tomasz Kłoczko wrote:
> On 1 April 2017 at 22:25, Neal Gompa  wrote:
> 
> > This is a libsolv test case. Fedora's high level package manager
> > (DNF[0]) uses libsolv[1] for its resolver engine. If you're trying
> > to
> > determine how something is going to behave, you can write a test
> > case
> > and use testsolv (in the libsolv-tools package) to run the test
> > case
> > and see what the solver would do. It gives you the ability to
> > reproducibly replay any kind of solution scenario. DNF will output
> > libsolv test cases for a given action when "--debugsolver" is added
> > as an option to the command.
> > 
> 
> And from your prev Igor email:
> 
> And please, stop spreading misinformation! As I said earlier, you
> have
> > to prove your information to FPC (which implies confirmation from
> > DNF
> > developers).
> 
> 
> So .. looks like:
> 1) your test case does not test what I've been testing (did you
> really
> download, try and look at it?).
> 2) Igor as well seems not been trying to test anything.
> 
> Because you guys (still) not even been trying to fire my test.
> Because what is inside of my original test case is not matching
> potential
> case when libsolve is used by dnf so I've wrote new test using not
> rpm but
> dnf.
> 
> OK. So in attachment is dnf-Obsolete-test.tar.gz. To fire test you
> need to
> execute test-dnf.sh
> In second attachment is test-dnf.result. If you will look inside you
> will
> find that I still can write:
> 
> Q.E.D.
> 
> So please guys .. go back to dnf developers and ask them do they
> homework
> because after flattering my nose and telling me to stop
> misinformations
> without spending few b*dy minutest on tests now it looks very bad.
> 
> BTW. After about 10min writing attached new test I've fired it second
> time
> to catch output to put in attachment but at the end of my script I've
> forgot to remove test 3.0 packages and my test started from
> installing test
> 1.0 packages and .. dnf downgraded test packages!!! =8-o
> So it is MAJOR dnf bug.
> Fragment from test output:
> 
> Downgrading:
>  test  x86_64   1.0-1  test
> 6.0 k
>  test-develx86_64   1.0-1  test
> 6.1 k
>  test-static   x86_64   1.0-1  test
> 6.1 k
> 
> Transaction Summary
> =
> ===
> Downgrade  3 Packages
> 
> Total size: 18 k
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> Transaction test succeeded.
> Running transaction
>   Preparing:
>  1/1
>   Downgrading  : test-1.0-1.x86_64
>  1/6
>   Downgrading  : test-devel-1.0-1.x86_64
>  2/6
>   Downgrading  : test-static-1.0-1.x86_64
> 3/6
>   Erasing  : test-static-3.0-1.x86_64
> 4/6
>   Erasing  : test-devel-3.0-1.x86_64
>  5/6
>   Erasing  : test-3.0-1.x86_64
>  6/6
>   Verifying: test-1.0-1.x86_64
>  1/6
>   Verifying: test-devel-1.0-1.x86_64
>  2/6
>   Verifying: test-static-1.0-1.x86_64
> 3/6
>   Verifying: test-3.0-1.x86_64
>  4/6
>   Verifying: test-devel-3.0-1.x86_64
>  5/6
>   Verifying: test-static-3.0-1.x86_64
> 6/6
> 
> Why it is the bug?
> Because:
> 
> $ dnf --help | grep downg
> downgrade Downgrade a package
> 
> and trying to do exactly the same using rpm:
> 
> # rpm -Uvh test-1.0-1.x86_64.rpm test-devel-1.0-1.x86_64.rpm
> test-static-1.0-1.x86_64.rpm
> Preparing...  ###
> ##
> [100%]
> package test-3.0-1.x86_64 (which is newer than test-1.0-1.x86_64) is
> already installed
> package test-devel-3.0-1.x86_64 (which is newer than
> test-devel-1.0-1.x86_64) is already installed
> package test-static-3.0-1.x86_64 (which is newer than
> test-static-1.0-1.x86_64) is already installed
{-U|--upgrade} <-- upgrade != downgrade
> 
> Test case for this bug is included in test-dnf.sh and result in
> attached
> .result file as well.
> 
> Second minor bug in displayed messages. On upgrade 1.0->2.0:
> 
> Upgrading:
>  test  x86_642.0-1test
>  6.1 k
>  replacing  test-static.x86_64 1.0-1
>  test-develx86_642.0-1test
>  6.1 k
> 
> This is not replace operation but obsoletion.
> In below log of operations on packages is correct message:
> 
>   Obsoleting   : test-static-1.0-1.x86_64
> 3/5
> 
> Now I have much more questions but I have only few minutes.
> Seems today in UK will be nice sunny day so maybe will try to write a
> bit
> more late evening or tomorrow morning. First I need to read a bit
> more
> about libsolve and few other new pieces.
Don't bother.

All your points here are basically going to /dev/null if you are not
going to contact FPC. You can be even right in some aspects, but just

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 1 April 2017 at 22:25, Neal Gompa  wrote:

> This is a libsolv test case. Fedora's high level package manager
> (DNF[0]) uses libsolv[1] for its resolver engine. If you're trying to
> determine how something is going to behave, you can write a test case
> and use testsolv (in the libsolv-tools package) to run the test case
> and see what the solver would do. It gives you the ability to
> reproducibly replay any kind of solution scenario. DNF will output
> libsolv test cases for a given action when "--debugsolver" is added
> as an option to the command.
>

And from your prev Igor email:

And please, stop spreading misinformation! As I said earlier, you have
> to prove your information to FPC (which implies confirmation from DNF
> developers).


So .. looks like:
1) your test case does not test what I've been testing (did you really
download, try and look at it?).
2) Igor as well seems not been trying to test anything.

Because you guys (still) not even been trying to fire my test.
Because what is inside of my original test case is not matching potential
case when libsolve is used by dnf so I've wrote new test using not rpm but
dnf.

OK. So in attachment is dnf-Obsolete-test.tar.gz. To fire test you need to
execute test-dnf.sh
In second attachment is test-dnf.result. If you will look inside you will
find that I still can write:

Q.E.D.

So please guys .. go back to dnf developers and ask them do they homework
because after flattering my nose and telling me to stop misinformations
without spending few b*dy minutest on tests now it looks very bad.

BTW. After about 10min writing attached new test I've fired it second time
to catch output to put in attachment but at the end of my script I've
forgot to remove test 3.0 packages and my test started from installing test
1.0 packages and .. dnf downgraded test packages!!! =8-o
So it is MAJOR dnf bug.
Fragment from test output:

Downgrading:
 test  x86_64   1.0-1  test
6.0 k
 test-develx86_64   1.0-1  test
6.1 k
 test-static   x86_64   1.0-1  test
6.1 k

Transaction Summary

Downgrade  3 Packages

Total size: 18 k
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing:
 1/1
  Downgrading  : test-1.0-1.x86_64
 1/6
  Downgrading  : test-devel-1.0-1.x86_64
 2/6
  Downgrading  : test-static-1.0-1.x86_64
3/6
  Erasing  : test-static-3.0-1.x86_64
4/6
  Erasing  : test-devel-3.0-1.x86_64
 5/6
  Erasing  : test-3.0-1.x86_64
 6/6
  Verifying: test-1.0-1.x86_64
 1/6
  Verifying: test-devel-1.0-1.x86_64
 2/6
  Verifying: test-static-1.0-1.x86_64
3/6
  Verifying: test-3.0-1.x86_64
 4/6
  Verifying: test-devel-3.0-1.x86_64
 5/6
  Verifying: test-static-3.0-1.x86_64
6/6

Why it is the bug?
Because:

$ dnf --help | grep downg
downgrade Downgrade a package

and trying to do exactly the same using rpm:

# rpm -Uvh test-1.0-1.x86_64.rpm test-devel-1.0-1.x86_64.rpm
test-static-1.0-1.x86_64.rpm
Preparing...  #
[100%]
package test-3.0-1.x86_64 (which is newer than test-1.0-1.x86_64) is
already installed
package test-devel-3.0-1.x86_64 (which is newer than
test-devel-1.0-1.x86_64) is already installed
package test-static-3.0-1.x86_64 (which is newer than
test-static-1.0-1.x86_64) is already installed

Test case for this bug is included in test-dnf.sh and result in attached
.result file as well.

Second minor bug in displayed messages. On upgrade 1.0->2.0:

Upgrading:
 test  x86_642.0-1test
 6.1 k
 replacing  test-static.x86_64 1.0-1
 test-develx86_642.0-1test
 6.1 k

This is not replace operation but obsoletion.
In below log of operations on packages is correct message:

  Obsoleting   : test-static-1.0-1.x86_64
3/5

Now I have much more questions but I have only few minutes.
Seems today in UK will be nice sunny day so maybe will try to write a bit
more late evening or tomorrow morning. First I need to read a bit more
about libsolve and few other new pieces.

I'll write first one:
Why dnf guys started playing with writing from scratch completely new
resolver, recommending even dnf as new package manager (which implies rpm
obsoletion .. soon; I'm sure that many people are not fully aware of this)
instead extracting base resolver from rpm code and wrapping it by new code?
(First sentence which I've learn during my first job in UK was "don't move,
improve")
dnf used to be only adding on top of raw rpm possibility to operate on
packages repositories. For some reason someone decided to replace rpm
adding of course in new code bugs which even 20 years ago in rpm

Re: Mass issue: /usr/bin/env dependency

[Neal Gompa]

On Sat, Apr 1, 2017 at 3:03 PM, Tomasz Kłoczko  wrote:
>
> On 1 April 2017 at 18:54, Igor Gnatenko 
> wrote:
>>
>> repo system 0 testtags 
>> #>=Pkg: foo-static 1 1 x86_64
>> repo available 0 testtags 
>> #>=Pkg: bar 1 1 x86_64
>> #>=Obs: foo-static
>> #>=Pkg: foo-static 2 1 x86_64
>> system x86_64 rpm system
>> poolflags implicitobsoleteusescolors
>> solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy
>> keeporphans yumobsoletes
>> job update all packages
>> result transaction,problems 
>> #>erase foo-static-1-1.x86_64@system bar-1-1.x86_64@available
>> #>install bar-1-1.x86_64@available
>
>
> May I ask what it is?
>

This is a libsolv test case. Fedora's high level package manager
(DNF[0]) uses libsolv[1] for its resolver engine. If you're trying to
determine how something is going to behave, you can write a test case
and use testsolv (in the libsolv-tools package) to run the test case
and see what the solver would do. It gives you the ability to
reproducibly replay any kind of solution scenario. DNF will output
libsolv test cases for a given action when "--debugsolver" is added
as an option to the command.

[0]: https://github.com/rpm-software-management/dnf
[1]: https://github.com/openSUSE/libsolv

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 1 April 2017 at 18:54, Igor Gnatenko 
wrote:

> repo system 0 testtags 
> #>=Pkg: foo-static 1 1 x86_64
> repo available 0 testtags 
> #>=Pkg: bar 1 1 x86_64
> #>=Obs: foo-static
> #>=Pkg: foo-static 2 1 x86_64
> system x86_64 rpm system
> poolflags implicitobsoleteusescolors
> solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy
> keeporphans yumobsoletes
> job update all packages
> result transaction,problems 
> #>erase foo-static-1-1.x86_64@system bar-1-1.x86_64@available
> #>install bar-1-1.x86_64@available
>

May I ask what it is?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2017-04-01 at 15:52 +0100, Tomasz Kłoczko wrote:
> On 1 April 2017 at 08:19, Michael Schwendt 
> wrote:
> 
> > In reality, that's not case always. In order to remove a previously
> > 
> 
> introduced Obsoletes tag, you would need to do what exactly?
> > 
> 
> I've already wrote this straight. Quote:
> 
> "So exact paragraph in FPG should be not about using versioned
> Obsolete
> rule but should contain straight rule that "resurrecting" package
> should
> cause remove Obsolete rule as consequence such decision."
> 
> I've as well implemented and posted test case which presents how such
> cases
> should be implemented.
> In other words: despite natural language explanations (which I've
> gave
> probably 3-4 variants) you have "by example" demonstration with which
> you
> can play or modify presenting that after modification something is
> not
> working ass expected.
> Please start playing with those specs files which I've posted.
> *Do not trust my words and please rely ONLY on what you can
> execute!!!*
> 
> I fully understand that it is not easy to understand some new
> approach if
> so long so many people been using some other variant which suppose to
> be
> correct but is not.
> 
> One more time: posted here test case works and does not need
> versioned
> Obsoletes rules.
> Does it really not lights up some bulb inside your mind? .. maybe at
> least
> some small spark?
> 
> Reality is that Fedora have been using wrong solution such scenario
> that
> now many people mentally have problem with accepting that it is
> other/better/simler solution. Such communal effect is *well known* in
> psychology.
> 
> If you want to proof that I'm wrong just *please do not continue
> sending
> next comments* in this thread. It is completely pointless!!
> Take test case which I've posted and modify it to the state when it
> will
> start producing not expected results or change something in context
> of the
> packages in which such short test is executed.
> So far no one here even one time posted something which may look like
> like
> producing not expected results.
> 
> We've come a long way, and returning to day zero and repeating some
> > mistakes is not a good idea.
> 
> 
> Look .. Fedora exist only 14 years.
> People been thinking that the Earth is centre of the Universe for
> thousands
> years.
> If something IS wrong time has no matter.
> Time, trust, number of people .. those things should not be brought
> here as
> an argument. Because it is not the "nec Hercules contra plures" case.
> No .. as I've been able implement and post test case with results
> *I'm
> longer not a side of this dispute*. Do you see this?
> At the moment you are trying to convince this ~1KB of tar.xz archive
> to
> start producing different results than I've posted.
> It takes only few seconds to download attachment and execute what is
> inside. (Rhetorical question) Did you try do this?
> If yes .. did you try after this spend few seconds asking yourself
> "why
> this annoying guy implement this exactly that way? Why it works? Can
> this
> test work correctly in case all past cases which caused writing some
> part
> of FPG? Can it work always?"
> 
> To everyone: instead spending time on writing reply *please* invest
> exactly
> the same time to execute and analyse what is inside this tests ..
repo system 0 testtags 
#>=Pkg: foo-static 1 1 x86_64
repo available 0 testtags 
#>=Pkg: bar 1 1 x86_64
#>=Obs: foo-static
#>=Pkg: foo-static 2 1 x86_64
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy
keeporphans yumobsoletes
job update all packages 
result transaction,problems 
#>erase foo-static-1-1.x86_64@system bar-1-1.x86_64@available
#>install bar-1-1.x86_64@available

And please, stop spreading misinformation! As I said earlier, you have
to prove your information to FPC (which implies confirmation from DNF
developers).
> kloczek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljf6VQACgkQaVcUvRu8
X0zUag/+Nqp4BYYMnJN6C4SmRUcQbTS5TlPaCEiuCOGv+o84EbWnQ2/7JqTglNu7
w8iOeNF+3Dp+krt3oqSDPSxn7RNFKu/uiZiDqqx7YSGqcIlZRHT04C42KlmaKXYN
tGWXyWdz0uudV1hMYYzmd/iHNvfr0PJ34ukbdPcc+z0+CuJZPwQKJDRp+f6eNWBM
bq1K0BHJOjkT6JU+94Gzj/cYK9KKT+SHQDehrYKZh2BPRVdd7HQFSqVeMqooYSC1
1eaMEBT1kTXkgA5tsf98ud2K2mWJHHI+L5sBB3vkwRSUt7i6HwZtv43SBO+kPsWY
x96V5wHjW1T500QJhejNP3Cror0v19yjgnpb88CNSEF/v8pxzdqyAEwYrl7wkUvI
ySX4t4j1XUfsgSggqKIyJolnxo9fWDB0zc1bf5ubrbSvJJu8Oo4TO34/+Gy1ANkX
iiwUCtiKCJwKMVjKYkNou88xjF2Mwh6rzNke79FpL7N6+9Ndu/1D8FKTMH/Uft9n
z4dUa+Z6Tu4JdMfg4qIOPL4i+8h39Japw5+7kuM3Dc4YswDlMqljG+C9NY0qgMW0
WX96exuDlWnE9ar4uQ5drDz+kMt5RKaBzb1TFc3dVs2dybF74CRuvlB2ovJ97LGf

Re: Mass issue: /usr/bin/env dependency

[Michael Schwendt]

On Sat, 1 Apr 2017 15:52:53 +0100, Tomasz Kłoczko wrote:

> Please start playing with those specs files which I've posted.

You have seen my reply to that faulty test case of yours, haven't you.
Nothing would change.

> I fully understand that it is not easy to understand some new approach if
> so long so many people been using some other variant which suppose to be
> correct but is not.

It is the opposite. It is _you_, who would need to look under the hood
and figure out the exact behaviour of RPM and related package tools. See
whether the behaviour is well-defined. Talk to the developers and find out
which problems and pitfalls they are aware of and how they want to handle
them.

Alternatively, come up with a new definition of how RPM and related tools
ought to handle Obsoletes tags and related update/upgrade/downgrade
scenarios, and convince the developers that changing behavior would be
worthwhile.

> Does it really not lights up some bulb inside your mind? .. maybe at least
> some small spark?

Enough is enough! It's sad you've had to turn that way. I've got something
else for you at this point:

*plonk*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 1 April 2017 at 08:19, Michael Schwendt  wrote:

> In reality, that's not case always. In order to remove a previously
>
introduced Obsoletes tag, you would need to do what exactly?
>

I've already wrote this straight. Quote:

"So exact paragraph in FPG should be not about using versioned Obsolete
rule but should contain straight rule that "resurrecting" package should
cause remove Obsolete rule as consequence such decision."

I've as well implemented and posted test case which presents how such cases
should be implemented.
In other words: despite natural language explanations (which I've gave
probably 3-4 variants) you have "by example" demonstration with which you
can play or modify presenting that after modification something is not
working ass expected.
Please start playing with those specs files which I've posted.
*Do not trust my words and please rely ONLY on what you can execute!!!*

I fully understand that it is not easy to understand some new approach if
so long so many people been using some other variant which suppose to be
correct but is not.

One more time: posted here test case works and does not need versioned
Obsoletes rules.
Does it really not lights up some bulb inside your mind? .. maybe at least
some small spark?

Reality is that Fedora have been using wrong solution such scenario that
now many people mentally have problem with accepting that it is
other/better/simler solution. Such communal effect is *well known* in
psychology.

If you want to proof that I'm wrong just *please do not continue sending
next comments* in this thread. It is completely pointless!!
Take test case which I've posted and modify it to the state when it will
start producing not expected results or change something in context of the
packages in which such short test is executed.
So far no one here even one time posted something which may look like like
producing not expected results.

We've come a long way, and returning to day zero and repeating some
> mistakes is not a good idea.


Look .. Fedora exist only 14 years.
People been thinking that the Earth is centre of the Universe for thousands
years.
If something IS wrong time has no matter.
Time, trust, number of people .. those things should not be brought here as
an argument. Because it is not the "nec Hercules contra plures" case.
No .. as I've been able implement and post test case with results *I'm
longer not a side of this dispute*. Do you see this?
At the moment you are trying to convince this ~1KB of tar.xz archive to
start producing different results than I've posted.
It takes only few seconds to download attachment and execute what is
inside. (Rhetorical question) Did you try do this?
If yes .. did you try after this spend few seconds asking yourself "why
this annoying guy implement this exactly that way? Why it works? Can this
test work correctly in case all past cases which caused writing some part
of FPG? Can it work always?"

To everyone: instead spending time on writing reply *please* invest exactly
the same time to execute and analyse what is inside this tests ..

kloczek
-- 
Tomasz Kłoczko |  LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Michael Schwendt]

On Fri, 31 Mar 2017 22:44:27 +0100, Tomasz Kłoczko wrote:

> OK so it is exactly like trying to fix the C code issue with left some
> parts of last changes iteration  which should be fixed by deleted such
> lines completely and instead such deletion someone is implementing  jump
> over such left part :)
> This is not is not a solution ..

No idea how that could be an analogy! Obviously, it would not matter at
all, if the programmer deleted lines actually or commented them out or
wrapped them in an #if 0 block, provided that the compiled code would
work correctly then. There may even be a good reason why not to delete
lines, such as giving a co-developer a chance to do proof-reading and
bug-hunting before deciding whether to delete anything or whether to
fix it.

> If it is still not clear will try to explain it on pure physics
> (thermodynamics) background.

... checking date ... hmmm ...

> Q.E.D.

You've not proven anything yet.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Michael Schwendt]

On Fri, 31 Mar 2017 21:10:29 +0100, Tomasz Kłoczko wrote:

> According to those two "laws" at the moment *I think* that what it was
> codified in FPG was caused by something stupid :)
> Lets say .. it was something like misinterpretation when in on upgrade test
> package from 2.0 to 3.0 someone forgot to remove "Obsolete: test-static".
> At the moment it is IMO *only* working hypothesis that it was exactly
> something like this, Other even less likely possibility is that it some bug
> in rpm (IMO possibility close to zero)

With all due respect, while trying to reinvent the wheel is not a bad idea
in general sometimes, throwing away the experience bears many risks.

Again you restrict yourself to that over-simplified scenario, where it's
the same package that governs the Obsoletes tag *and* the [sub]package to
obsolete.

In reality, that's not case always. In order to remove a previously
introduced Obsoletes tag, you would need to do what exactly? Replace the
package, which contains that tag, wherever it is found. Where exactly is
that? And how to achieve that? Suppose it's LibreOffice that has replaced
a plugin, which would be reintroduced as a separate package. Would you
release a superfluous update to everyone only to remove an Obsoletes tag?
Or if it were a kernel package replacing a separate kernel-module driver
package, would you release a superfluous kernel update to everyone only to
remove an Obsoletes tag? Btw, that wouldn't even work, because multiple
releases of such packages can remain installed.
And in the repos, multiple releases of a package remain available to be
accessed by the users. It may be multiple releases spread to multiple
repos or multiple releases in a single updates repo even. If you wanted to
restrict yourself to a single package release in all enabled repos, you
would also need to delete an old build originally published at dist
release time, because it had added an Obsoletes tag you wanted to remove.
Keeping the package in the repo, but hiding it from the metadata (as in
only offering latest EVR but not obsolete ones) would not be any different.

We've come a long way, and returning to day zero and repeating some
mistakes is not a good idea.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 31 March 2017 at 20:56, Michael Schwendt  wrote:

> Now repeat the same with a set of packages where the Obsoletes tag
> remains in one of the packages
>

OK so it is exactly like trying to fix the C code issue with left some
parts of last changes iteration  which should be fixed by deleted such
lines completely and instead such deletion someone is implementing  jump
over such left part :)
This is not is not a solution ..

So exact paragraph in FPG should be not about using versioned Obsolete rule
but should contain straight rule that "resurrecting" package should cause
remove Obsolete rule as consequence such decision.

If it is still not clear will try to explain it on pure physics
(thermodynamics) background.
Someone mistakes by living such Obsoletes rules should be not supported by
FPG advice because this approach *increases packages internal entropy*.
Adding Obsoletes rule increases such entropy (it enriches package
description). As you know it is not possible to decrease entropy in
isolated system without spending additional energy. Such energy should be
spent precisely on *remove Obsolete rule* in last step of test scenario.

Or in energy terms: bringing back some package to full use must be done
with remove Obsolete rule because it is lowest possible system energy state.

Or in plain form: someone mistake/error cannot be solved by leaving such
error/mistake as-it-is and adding even more complicated wrapping rule which
preserves such such mistake forever.

And last explanation pure on rpm background: every time when package like
test-static is produced it carries not straight visable rule about
obsoleting *all older versions of packages A-static*. Preserving explicit
in spec file versioned Obsoletes rule *duplicates logic of internal rpm
dependency resolver processed rules*. It is some possibility that in even
more complicated cases which I cannot describe now such fixed/explicit in
spec rule will cause another pathological case. Risk is small but still
non-zero.
Let's try to think about our example test-static 3.0 package but without
past. If leaving "Obsolete: test-static < 2.0-1" is correct it must cause
that every other distribution  package must have now "Obsolete: 
< " as well. No one is using such approach!!! Nonsense ..
isn't it?
Why bringing such example has sense here? Because what for some packages
maintainers has past, for some packages "consumers" has no such past ..
they are installing such package on fresh system.
As I proved to handle cases with and and without past is possible using
specs with remove Obsolete line when package like test-static returns to
life.

Q.E.D.
IMO .. case is closed.

Now I know why I had problem with understanding this scenario because
leaving Obsolete line for me was and still is completely irrational so
initially I've not been even thinking after more than 20 years of using rpm
someone decided to use it incorrectly !!! :)

To all: have good weekend :)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unversioned Obsoletes (was Re: Mass issue: /usr/bin/env dependency)

[Fernando Nasser]

On 2017-03-31 4:04 PM, Michael Schwendt wrote:

On Fri, 31 Mar 2017 15:16:22 -0400, Fernando Nasser wrote:


A few issues I remember caused by unversioned Obsoletes (before they
were banished to Hell) were:

- Not being able, ever again, to provide the thing being obsoleted.  And
believe me, things change ;-)

- The Obsoletes affects other channels as well, not only the content of
the channel that contains the package that contains the Obsoletes is
affected.\
If the obsoleted name is needed by something in some other package even
being at a higher version it cannot be installed.

So for a decade or more (I list track, I am here for almost 2 decades),
the Obsoletes always comes with a '=' or a '<='.

RPM itself also blocks a package from being installed, if *any* other
installed packages obsoletes that package name. If non-versioned, you're
doomed and would need to get rid of the Obsoletes tag first.

An overly simplified test-case where the package containing the Obsoletes
tag is replaced directly via rpm -Uvh is not sufficient.


One has to resort to triggers, and even that does not work in all cases.

Wretched thing, unversioned Obsoletes.

Fernando



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 31 March 2017 at 20:05, Rex Dieter  wrote:

> If you think versioned Obsoletes are bad or unwise, it shows some naivety
> or
> inexperience:  Ever had to fix/recover from erroneous Obsoletes or had to
> deal with undo/revert of them (without resorting to introducing epoch)?
>
> I suggest you place a little more trust those who have more experience
> (like
> current or former FPC members) on the topic.
>

No .. please. Don't try to think about I may be thinking. This is pointless
:)
And no, I'm not thinking about thing which you wrote :)

As an engineer many years ago I've formed two "laws" about errors/bad cases
1) All bad/error cases you can put only in two baskets: *simple* and
*stupid*
2) Longer time you are working on some issues than *probability* that it is
something stupid *is only growing*.

According to those two "laws" at the moment *I think* that what it was
codified in FPG was caused by something stupid :)
Lets say .. it was something like misinterpretation when in on upgrade test
package from 2.0 to 3.0 someone forgot to remove "Obsolete: test-static".
At the moment it is IMO *only* working hypothesis that it was exactly
something like this, Other even less likely possibility is that it some bug
in rpm (IMO possibility close to zero)

However if it was something like this forming such advice in FPG someone
siple lost from the radar that in 3.0 Obsolete line should be *removed*.
Such case is like trying to fix in C some issue with code not removed after
last changes iteration not by removing those lines but by unconditional
jump over such fragment.

If it will be like this it will be no one error. Simple such things
sometimes happens ..
Again as an engineer I can tell that making mistakes is not en issue.
Problem is when such mistakes happens many times not causing any procedural
changes.
This is what exactly says old Latin sentence "Errare humanum est, sed in
errare perseverare diabolicum" which can be translated as "To err is human,
but to persist in error is diabolical".
(I like more quite old Polish translation which a bit more poetical
"błądzić jest rzeczą ludzką ale zbawienną powstawać z upadku" which is
without "diabolical" connotation :) )

Together here we have enough knowledge and experience to not relay on
*trust*.
So .. please back together to the meritum.
Let's try to reproduce exactly this case which caused forming (MO
incorrect) advice in FPG :)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unversioned Obsoletes (was Re: Mass issue: /usr/bin/env dependency)

[Michael Schwendt]

On Fri, 31 Mar 2017 15:16:22 -0400, Fernando Nasser wrote:

> A few issues I remember caused by unversioned Obsoletes (before they 
> were banished to Hell) were:
> 
> - Not being able, ever again, to provide the thing being obsoleted.  And 
> believe me, things change ;-)
> 
> - The Obsoletes affects other channels as well, not only the content of 
> the channel that contains the package that contains the Obsoletes is 
> affected.\
> If the obsoleted name is needed by something in some other package even 
> being at a higher version it cannot be installed.
> 
> So for a decade or more (I list track, I am here for almost 2 decades), 
> the Obsoletes always comes with a '=' or a '<='.

RPM itself also blocks a package from being installed, if *any* other
installed packages obsoletes that package name. If non-versioned, you're
doomed and would need to get rid of the Obsoletes tag first.

An overly simplified test-case where the package containing the Obsoletes
tag is replaced directly via rpm -Uvh is not sufficient.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Michael Schwendt]

On Fri, 31 Mar 2017 19:41:30 +0100, Tomasz Kłoczko wrote:

> OK. Could you please show me example?

Any non-versioned Obsoletes tag in the repo metadata hides the obsolete
package from the depsolver's view during updates, and depending on the
implementation even during first installs.

> It is yet another possibility tat it may be result of using yum/dnf which
> are working not exactly the same as rpm.

True.

> I have no idea about what kind scenario you are talking about

src.rpm "foo" building base package "foo-2.0-1" and subpkg "libfoo-2.0-1"
for some shared libs. Eventually, libfoo is released independently as a
separate project, starting with version 0.1. Packager can only reduce
version from 2.0 to 0.1 via an Epoch bump or by replacing the old libfoo
with a differently named package. Replacing packages involves obsoleting
them, and in turn you would *not* want to block the "libfoo" package
namespace forever. The original "foo" subpkg builds may want to put other
libs into the libfoo subpkg, if there is not separate libfoo base package
built from a different src.rpm.

> As I wrote engineering is about testing so here is my test case:
> Four spec files and two scripts.

The test is faulty. What results did you expect? Since you ask RPM
to update specific packages, it does exactly that, of course. Once the
package containing the Obsoletes tag has been replaced, what behaviour
did you expect from the third -Uvh? Of course, it installs all three
test packages you've asked for.

Now repeat the same with a set of packages where the Obsoletes tag
remains in one of the packages. If you do that with Yum or DNF and a local
repo out of convenience, the obsolete package won't be available anymore.
You may be able to install it once, if you ask for it specifically, but
any subsequent update will obsolete it again and hide all builds that are
covered by the Obsoletes tag.
If you do it with rpm -Uvh, RPM tries to help you and evaluates the
packages prior to the update transaction. It tries to reduce the set of
packages to those with highest EVR, but it also handles Obsoletes tags,
and if any packages near the end of the command-line contain Obsoletes
tags, those will be evaluated, and you would not be able to get your
test-static-3.0 package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unversioned Obsoletes (was Re: Mass issue: /usr/bin/env dependency)

[Fernando Nasser]

A few issues I remember caused by unversioned Obsoletes (before they 
were banished to Hell) were:


- Not being able, ever again, to provide the thing being obsoleted.  And 
believe me, things change ;-)


- The Obsoletes affects other channels as well, not only the content of 
the channel that contains the package that contains the Obsoletes is 
affected.\
If the obsoleted name is needed by something in some other package even 
being at a higher version it cannot be installed.


So for a decade or more (I list track, I am here for almost 2 decades), 
the Obsoletes always comes with a '=' or a '<='.


Regards,
Fernando


On 2017-03-31 3:08 PM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2017-03-31 at 19:41 +0100, Tomasz Kłoczko wrote:

On 31 March 2017 at 17:57, Michael Schwendt 
wrote:


No, it's based on common experience several packagers have made
over a
period of several years. You seem to have missed that period. Non-
versioned
Obsoletes have caused problems before.


OK. Could you please show me example? Best if it will be documented
for
example in bugzilla.
I'm almost sure that it is kind of mistake or results
misinterpretation.

It is yet another possibility tat it may be result of using yum/dnf
which
are working not exactly the same as rpm.

[..]


What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1"
and just
"Obsolete: A-static" when new 3.0 will arrive?

What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was
installed
before? Of course A-static will be uninstalled.

What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no
longer
carries Obsolete rule -> A and A-static will be upgraded
together.

No. The exact behaviour is implementation dependent. As long as the
Obsoletes tag is seen by the dependency resolver when examining
installed
packages and available packages, the obsolete package is not taken
into
consideration when resolving dependencies. Its EVR is irrelevant
then.
It will not become an update or upgrade. It is obsolete.

Below you added a wall of text once again. Your passion for this
topic
is admirable, but it won't lead to anything, if you refuse to be
much more
short and concise.


I have no idea about what kind scenario you are talking about so I
made my
tests.
As I wrote engineering is about testing so here is my test case:
Four spec files and two scripts.
First one has:

rm -f ~/rpmbuild/RPMS/x86_64/test*
rpmbuild -ba --quiet test-1.0.spec test-2.0.spec test-3.0.spec
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*1.0*
rpm -qa | grep ^test
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*2.0*
rpm -qa | grep ^test
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*3.0*
rpm -qa | grep ^test

Here is my result:

$ sh ./test.sh
rpm: no packages given for erase
Preparing...  ###
##
[100%]
Updating / installing...
1:test-1.0-
1   # [
33%]
2:test-devel-1.0-
1 # [
67%]
3:test-static-1.0-
1#
[100%]
test-1.0-1.x86_64
test-devel-1.0-1.x86_64
test-static-1.0-1.x86_64
Preparing...  ###
##
[100%]
Updating / installing...
1:test-2.0-
1   # [
20%]
2:test-devel-2.0-
1 # [
40%]
Cleaning up / removing...
3:test-static-1.0-
1# [
60%]
4:test-devel-1.0-
1 # [
80%]
5:test-1.0-
1   #
[100%]
test-2.0-1.x86_64
test-devel-2.0-1.x86_64
Preparing...  ###
##
[100%]
Updating / installing...
1:test-3.0-
1   # [
20%]
2:test-devel-3.0-
1 # [
40%]
3:test-static-3.0-
1# [
60%]
Cleaning up / removing...
4:test-devel-2.0-
1 # [
80%]
5:test-2.0-
1   #
[100%]
test-devel-3.0-1.x86_64
test-static-3.0-1.x86_64
test-3.0-1.x86_64

And second test on with test-2.0-ver.spec which has changed:

--- test-2.0.spec 2017-03-31 18:55:05.986642900 +0100
+++ test-2.0-ver.spec 2017-03-31 18:55:52.877882709 +0100
@@ -3,7 +3,7 @@
  Version: 2.0
  Release: 1
  License: Test
-Obsoletes: test-static
+Obsoletes: test-static < 2.0-1

  %description
  Test package.

Result:

$ sh ./test-ver.sh
Preparing...  ###
##
[100%]
Updating / installing...
1:test-1.0-
1   # [
33%]
2:test-devel-1.0-
1 

Unversioned Obsoletes (was Re: Mass issue: /usr/bin/env dependency)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2017-03-31 at 19:41 +0100, Tomasz Kłoczko wrote:
> On 31 March 2017 at 17:57, Michael Schwendt 
> wrote:
> 
> > No, it's based on common experience several packagers have made
> > over a
> > period of several years. You seem to have missed that period. Non-
> > versioned
> > Obsoletes have caused problems before.
> > 
> 
> OK. Could you please show me example? Best if it will be documented
> for
> example in bugzilla.
> I'm almost sure that it is kind of mistake or results
> misinterpretation.
> 
> It is yet another possibility tat it may be result of using yum/dnf
> which
> are working not exactly the same as rpm.
> 
> [..]
> 
> > > What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1"
> > > and just
> > > "Obsolete: A-static" when new 3.0 will arrive?
> > > 
> > > What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was
> > > installed
> > > before? Of course A-static will be uninstalled.
> > > 
> > > What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no
> > > longer
> > > carries Obsolete rule -> A and A-static will be upgraded
> > > together.
> > 
> > No. The exact behaviour is implementation dependent. As long as the
> > Obsoletes tag is seen by the dependency resolver when examining
> > installed
> > packages and available packages, the obsolete package is not taken
> > into
> > consideration when resolving dependencies. Its EVR is irrelevant
> > then.
> > It will not become an update or upgrade. It is obsolete.
> > 
> > Below you added a wall of text once again. Your passion for this
> > topic
> > is admirable, but it won't lead to anything, if you refuse to be
> > much more
> > short and concise.
> > 
> 
> I have no idea about what kind scenario you are talking about so I
> made my
> tests.
> As I wrote engineering is about testing so here is my test case:
> Four spec files and two scripts.
> First one has:
> 
> rm -f ~/rpmbuild/RPMS/x86_64/test*
> rpmbuild -ba --quiet test-1.0.spec test-2.0.spec test-3.0.spec
> sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*1.0*
> rpm -qa | grep ^test
> sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*2.0*
> rpm -qa | grep ^test
> sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*3.0*
> rpm -qa | grep ^test
> 
> Here is my result:
> 
> $ sh ./test.sh
> rpm: no packages given for erase
> Preparing...  ###
> ##
> [100%]
> Updating / installing...
>    1:test-1.0-
> 1   # [
> 33%]
>    2:test-devel-1.0-
> 1 # [
> 67%]
>    3:test-static-1.0-
> 1#
> [100%]
> test-1.0-1.x86_64
> test-devel-1.0-1.x86_64
> test-static-1.0-1.x86_64
> Preparing...  ###
> ##
> [100%]
> Updating / installing...
>    1:test-2.0-
> 1   # [
> 20%]
>    2:test-devel-2.0-
> 1 # [
> 40%]
> Cleaning up / removing...
>    3:test-static-1.0-
> 1# [
> 60%]
>    4:test-devel-1.0-
> 1 # [
> 80%]
>    5:test-1.0-
> 1   #
> [100%]
> test-2.0-1.x86_64
> test-devel-2.0-1.x86_64
> Preparing...  ###
> ##
> [100%]
> Updating / installing...
>    1:test-3.0-
> 1   # [
> 20%]
>    2:test-devel-3.0-
> 1 # [
> 40%]
>    3:test-static-3.0-
> 1# [
> 60%]
> Cleaning up / removing...
>    4:test-devel-2.0-
> 1 # [
> 80%]
>    5:test-2.0-
> 1   #
> [100%]
> test-devel-3.0-1.x86_64
> test-static-3.0-1.x86_64
> test-3.0-1.x86_64
> 
> And second test on with test-2.0-ver.spec which has changed:
> 
> --- test-2.0.spec 2017-03-31 18:55:05.986642900 +0100
> +++ test-2.0-ver.spec 2017-03-31 18:55:52.877882709 +0100
> @@ -3,7 +3,7 @@
>  Version: 2.0
>  Release: 1
>  License: Test
> -Obsoletes: test-static
> +Obsoletes: test-static < 2.0-1
> 
>  %description
>  Test package.
> 
> Result:
> 
> $ sh ./test-ver.sh
> Preparing...  ###
> ##
> [100%]
> Updating / installing...
>    1:test-1.0-
> 1   # [
> 33%]
>    2:test-devel-1.0-
> 1 # [
> 67%]
>    3:test-static-1.0-
> 1#
> [100%]
> test-static-1.0-1.x86_64
> test-devel-1.0-1.x86_64
> test-1.0-1.x86_64
> Preparing...  ###
> ##
> [100%]
> Updating / installing...
>   

Re: Mass issue: /usr/bin/env dependency

[Rex Dieter]

Tomasz Kłoczko wrote:

> I see that you and other people proposing versioned Obsoletes rules never
> ever analysed step by step whole scenario(s) 

If you think versioned Obsoletes are bad or unwise, it shows some naivety or 
inexperience:  Ever had to fix/recover from erroneous Obsoletes or had to 
deal with undo/revert of them (without resorting to introducing epoch)?

I suggest you place a little more trust those who have more experience (like 
current or former FPC members) on the topic.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 31 March 2017 at 17:57, Michael Schwendt  wrote:

> No, it's based on common experience several packagers have made over a
> period of several years. You seem to have missed that period. Non-versioned
> Obsoletes have caused problems before.
>

OK. Could you please show me example? Best if it will be documented for
example in bugzilla.
I'm almost sure that it is kind of mistake or results misinterpretation.

It is yet another possibility tat it may be result of using yum/dnf which
are working not exactly the same as rpm.

[..]

> > What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1" and just
> > "Obsolete: A-static" when new 3.0 will arrive?
> >
> > What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was installed
> > before? Of course A-static will be uninstalled.
> >
> > What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no longer
> > carries Obsolete rule -> A and A-static will be upgraded together.
>
> No. The exact behaviour is implementation dependent. As long as the
> Obsoletes tag is seen by the dependency resolver when examining installed
> packages and available packages, the obsolete package is not taken into
> consideration when resolving dependencies. Its EVR is irrelevant then.
> It will not become an update or upgrade. It is obsolete.
>
> Below you added a wall of text once again. Your passion for this topic
> is admirable, but it won't lead to anything, if you refuse to be much more
> short and concise.
>

I have no idea about what kind scenario you are talking about so I made my
tests.
As I wrote engineering is about testing so here is my test case:
Four spec files and two scripts.
First one has:

rm -f ~/rpmbuild/RPMS/x86_64/test*
rpmbuild -ba --quiet test-1.0.spec test-2.0.spec test-3.0.spec
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*1.0*
rpm -qa | grep ^test
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*2.0*
rpm -qa | grep ^test
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*3.0*
rpm -qa | grep ^test

Here is my result:

$ sh ./test.sh
rpm: no packages given for erase
Preparing...  #
[100%]
Updating / installing...
   1:test-1.0-1   # [
33%]
   2:test-devel-1.0-1 # [
67%]
   3:test-static-1.0-1#
[100%]
test-1.0-1.x86_64
test-devel-1.0-1.x86_64
test-static-1.0-1.x86_64
Preparing...  #
[100%]
Updating / installing...
   1:test-2.0-1   # [
20%]
   2:test-devel-2.0-1 # [
40%]
Cleaning up / removing...
   3:test-static-1.0-1# [
60%]
   4:test-devel-1.0-1 # [
80%]
   5:test-1.0-1   #
[100%]
test-2.0-1.x86_64
test-devel-2.0-1.x86_64
Preparing...  #
[100%]
Updating / installing...
   1:test-3.0-1   # [
20%]
   2:test-devel-3.0-1 # [
40%]
   3:test-static-3.0-1# [
60%]
Cleaning up / removing...
   4:test-devel-2.0-1 # [
80%]
   5:test-2.0-1   #
[100%]
test-devel-3.0-1.x86_64
test-static-3.0-1.x86_64
test-3.0-1.x86_64

And second test on with test-2.0-ver.spec which has changed:

--- test-2.0.spec 2017-03-31 18:55:05.986642900 +0100
+++ test-2.0-ver.spec 2017-03-31 18:55:52.877882709 +0100
@@ -3,7 +3,7 @@
 Version: 2.0
 Release: 1
 License: Test
-Obsoletes: test-static
+Obsoletes: test-static < 2.0-1

 %description
 Test package.

Result:

$ sh ./test-ver.sh
Preparing...  #
[100%]
Updating / installing...
   1:test-1.0-1   # [
33%]
   2:test-devel-1.0-1 # [
67%]
   3:test-static-1.0-1#
[100%]
test-static-1.0-1.x86_64
test-devel-1.0-1.x86_64
test-1.0-1.x86_64
Preparing...  #
[100%]
Updating / installing...
   1:test-2.0-1   # [
20%]
   2:test-devel-2.0-1 # [
40%]
Cleaning up / removing...
   3:test-static-1.0-1# [
60%]
   4:test-devel-1.0-1 # [
80%]
   5:test-1.0-1   #
[100%]
test-devel-2.0-1.x86_64
test-2.0-1.x86_64
Preparing...  

Re: Mass issue: /usr/bin/env dependency

[Michael Schwendt]

On Fri, 31 Mar 2017 17:32:09 +0100, Tomasz Kłoczko wrote:

> I see that you and other people proposing versioned Obsoletes rules never
> ever analysed step by step whole scenario(s) or done kind of 10 min POC to
> prove correctness/incorrectness of this. Looks like again .. it is result
> of using (educated) guessing :(

No, it's based on common experience several packagers have made over a
period of several years. You seem to have missed that period. Non-versioned
Obsoletes have caused problems before.

> Let's try do this here step by step analysing exact scenarios with and
> without versioned Obsoletes.
> Package A, Version 1.0, release 1 has static subpackage
> Package A, Version 2.0, release 1 has no longer static subpackage and main
> A has obsolete rule for A-static
> Package A, Version 3.0, release 1 has again static subpackage and by this
> has no longer has obsolete rule for A-static.
> 
> Additional detail:
> For the record: all exactly this kind of packages should have "Requires:
> A-devel = %{version}-%release}" in static and A-devel should have at least
> "Requires: A = %{version}-%{release}". However in or case it is meaningless
> ..
> 
> What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1" and just
> "Obsolete: A-static" when new 3.0 will arrive?
> 
> What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was installed
> before? Of course A-static will be uninstalled.
> 
> What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no longer
> carries Obsolete rule -> A and A-static will be upgraded together.

No. The exact behaviour is implementation dependent. As long as the
Obsoletes tag is seen by the dependency resolver when examining installed
packages and available packages, the obsolete package is not taken into
consideration when resolving dependencies. Its EVR is irrelevant then.
It will not become an update or upgrade. It is obsolete.

Below you added a wall of text once again. Your passion for this topic
is admirable, but it won't lead to anything, if you refuse to be much more
short and concise.

> BTW Epoch. Using Epoch is only for scenario when it is necessary roll back
> to earlier version of *the same package* when such package *is installed*.

That's not true either. A package doesn't need to be installed at all, and
it doesn't need to be the "same package". In repo metadata highest EVR
wins version comparison. Again, depending on how the package tools and
depsolvers are implemented, you would not even see a package due to its
EVR. Also, there's the scenario of package splits, such as a library
getting released as a separate project with an own versioning scheme,
and Epoch is the only way to handle that, regardless of whether a package
is installed already.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 31 March 2017 at 12:00, Michael Schwendt  wrote:

> When you refer to removing a package "permanently", that is a fallacy.
> You cannot predict whether you may want to reintroduce a package some day.
> Even for a foo-static package there may be a reason why to build such a
> package again. Blocking a package name completely is not nice. It may be a
> 3rd party repo to reintroduce that package with a higher version or bumped
> Epoch. Or a local admin, who wants to keep it. Non-versioned Obsoletes
> make it more difficult to reintroduce the package, since you would need to
> get rid of the Obsoletes tags from installed packages *and* from the repo
> metadata first.
>
> Properly versioned Obsoletes also remove a package from the dist forever,
> provided that the package is not reintroduced in the future. Using macros
> is a trade-off, which also obsoletes any updates or upgrades the obsolete
> package may have had for older dist releases. Non-versioned Obsoletes is
> the big hammer and a sloppy solution. That a packager can violate the
> dist upgrade path is a general problem and not specific to versioned
> Obsoletes tags.
>

I see that you and other people proposing versioned Obsoletes rules never
ever analysed step by step whole scenario(s) or done kind of 10 min POC to
prove correctness/incorrectness of this. Looks like again .. it is result
of using (educated) guessing :(

OK, doesn't matter.

Let's try do this here step by step analysing exact scenarios with and
without versioned Obsoletes.
Package A, Version 1.0, release 1 has static subpackage
Package A, Version 2.0, release 1 has no longer static subpackage and main
A has obsolete rule for A-static
Package A, Version 3.0, release 1 has again static subpackage and by this
has no longer has obsolete rule for A-static.

Additional detail:
For the record: all exactly this kind of packages should have "Requires:
A-devel = %{version}-%release}" in static and A-devel should have at least
"Requires: A = %{version}-%{release}". However in or case it is meaningless
..

What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1" and just
"Obsolete: A-static" when new 3.0 will arrive?

What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was installed
before? Of course A-static will be uninstalled.

What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no longer
carries Obsolete rule -> A and A-static will be upgraded together.

Upgrade will be done as expected.
Above will happen no matter what kind dependencies are between A, A-devel
and A-static
Upgrade will be without errors no matter does A 3.0 contains versioned or
not versioned Obsolete because rm will in internal dependencies resolver
will reorder new A-3.0 package dependencies without obsolete *canceling
Obsolete rule from A-2.0 and what was exactly in those earlier A package
rules at such change of state is completely meaningless*

Conclusion: Using *versioned* Obsolete rules is pointless and here should
be used well known tool of logic (
https://en.wikipedia.org/wiki/Occam%27s_razor)

Q.E.D.

Exactly the same happens on swapping and rolling back swapping (sub)
packages names.
In other words:
- "permanent remove" package is never permanent and can be always rolled
back/reversed in next versions/releases. Such permanency is only matter of
agreement that we will (probably) never going to package something under
exact package name
- even current FPG point about swapping/changing packages names suggesting
use versioned is incorrect because swapping package names is like
"permanently remove package X .. but just for now". All works exactly this
way because as as I wrote "permanence of remove package X" is only matter
of some agreement and by definition is not possible to construct any
package names changes which will be not possible to reverse in next X
releases/versions.

What I wrote about using versioned Obsoletes rules is not a fallacy because
no one needs here to predict anything about future state of some packages
sets states.
Do you see this now?
.. your good intentions mixed with intuition tricked you. Don't worry you
are not the first and not the last :)
It is known that analyse consequences of +2 questions combined as long as
you are not kind of autistic person fails in case ~all humans on daily
bases.
Training/teaching The Engineers is about almost imprinting that this
threshold of fails is so close and main rule is testing, and testing again,
and again ..

So why I'm so sure that it works exactly like above? Because more than 20
years ago after writing first ever rpm spec file producing multiple
subpackages and publishing it (lesstif.spec) during my experiments but
before release it on RHCN ftp server I made typo in subpackage name. I
found it after I've installed those package on ~20 computers in Gdańsk
Technical Univ Physics Department student laboratory (to which as a student
I had root access). Because just before this I've organised my first
packages 

Re: Mass issue: /usr/bin/env dependency

[Michael Schwendt]

On Thu, 30 Mar 2017 19:05:54 +0100, Tomasz Kłoczko wrote:

> I see more and more issues related to FPG. And most discouraging is not
> what is inside FPG because I can agree with most of the advices in this
> document
> Seem some packagers are using it almost blindly. And we are not talking
> about few but something like almost majority.

That is not a new problem. The review queue, for example, is filled with
packages, which won't pass review and which require a lot of work, because
the submitters haven't even tried to review their packages themselves.
In other cases, packages are mispackaged. In extreme cases, they don't work
anymore once installed.

Fedora's Packaging Committee suggests that packagers post to the packaging@
mailing-list in case of doubt, not that packagers create non-working
[or otherwise mispackaged) packages only to meet the guidelines or
because of misunderstanding the guidelines. If anything is discouraging,
it is that some people hide in the review queue instead of getting active
and asking about something.

About your ramblings on Obsoletes:

When you refer to removing a package "permanently", that is a fallacy.
You cannot predict whether you may want to reintroduce a package some day.
Even for a foo-static package there may be a reason why to build such a
package again. Blocking a package name completely is not nice. It may be a
3rd party repo to reintroduce that package with a higher version or bumped
Epoch. Or a local admin, who wants to keep it. Non-versioned Obsoletes
make it more difficult to reintroduce the package, since you would need to
get rid of the Obsoletes tags from installed packages *and* from the repo
metadata first.

Properly versioned Obsoletes also remove a package from the dist forever,
provided that the package is not reintroduced in the future. Using macros
is a trade-off, which also obsoletes any updates or upgrades the obsolete
package may have had for older dist releases. Non-versioned Obsoletes is
the big hammer and a sloppy solution. That a packager can violate the
dist upgrade path is a general problem and not specific to versioned
Obsoletes tags.

No comment on the rest of your mail. TL;DR. I suggest you cut it into
smaller pieces, which make more clear what and how you're trying to improve
something.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Vít Ondruch]

Dne 30.3.2017 v 18:00 Stephen John Smoogen napsal(a):
>
> 4) There is a difference between rules written down and rules in
> action. While the rule has been this should be done, the fact that so
> many packages have never done so and no one has pulled them for that..
> says the real rule is it is not needed. Making a written rule an
> action rule takes enforcement which always causes resistance.
>
>

This was always just proposal. If it was in FPG, then it would be
different story.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 30 March 2017 at 20:01, Matthew Miller  wrote:

> You don't know whether the person you are replying to
> is "guessing" or whether they actually have experience and expertise
> which just happens to be different from yours. In fact, in this case, I
> will guarantee you that it's absolutely true.
>

Just one more note based on pure logic.
If someone has experience bases on maintaining some set of typical
small/trivial changes across thousands packages build/install/test
frameworks like I have, but this person has different post factum
experience/conclusion than mine.
Because Fedora has no policies (as as far as I know never had) about not
using /bin/bash in case when script is pure SH script or not using in
preamble /bin/sh when script is bash script, has no policy about not using
/usr/bin/env when it is only one possible to use interpreter, has no policy
about correcting linking with not need libraries, has no at least few
(maybe 3 or 4) similar such trivial to introduce (and IMO maintain)
policies *significantly reducing numbers of some issues related to many
dependencies between packages* ..
.. conclusion must be that such person possessed this experience not
working on Fedora (and/or close derivs like RH, Oracle Linux or CentOS). Am
I right?

Really I'm not asking about name or career details such person.
Jut please use as The Final Argument name of the OS/distribution on which
such changes have been introduced, maintained for some period of time
and/or abandoned as creating to many long term problems.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Stephen John Smoogen]

On 30 March 2017 at 14:48, Tomasz Kłoczko  wrote:
>
> On 30 March 2017 at 17:00, Stephen John Smoogen  wrote:
>>
>> 1) They are going to have 'non-upstream' patches for all their
>> software.. which is just one more thing to keep up with every update.
>>
>> 2) Most of this software is not stuff they care about. It is branches
>> on a tree for the only reason they packaged it up in the first place.
>> So it is busy work from what they want.
>>
>> 3) This isn't the only rodeo they are putting this package in. So this
>> patch set looks like a special snowflake patch they have to keep up
>> with.
>
>
> Majority (+95%) of the patches related to build, install and test suite
> framework used by project is never changing.
> /usr/bin/env changes are such changes because I've been able to observer
> within +3 years across few thousands packages.
> Some of those changes will be used as long as distribution will be actively
> maintained because it is really hard sometimes to maintain such build,
> install and test suite framework fulfilling all OSeses needs.
> Sometimes it is not about those that some source maintainers are kind of bab
> people.
> Sometimes some people maintaining some publically available code are earning
> money from maining such projects by offering paid support for such software.
> In such cases it is nothing bad that such people do not care abut people
> which are not giving then money using such software.
>
> As those changes are trivial maintaining them takes really small fraction of
> whole time necessary to upgrade package spec file between versions.
> My personal observation says me that within last decade more than +60% of
> such changes never been updated.
>
>
> Sorry to say this but you are guessing and guessing you may have such
> impression that above may be truth.
> Reality is different.
>
> I'm fully aware that proposing such widely spreading change I'm entering on
> some conflict/battle ground.
> I know that all long and/or complicated conflicts are possible to finish
> using only using two methods: by giving or taking away hope.
> Stephen you chose to discourage me .. noticed ;-P
> You must know something about me that I'm really hard nut and as long as you
> will be not giving me stricte technical/engineering arguments please expect
> that such argumentation will be crushed only on technical background using
> my exp, knowledge and/or thing which I've already done .. so I'm not using
> guessing like you :)
> Please stop using guessing :)

This goes both ways.. as it is clear you are guessing my intentions
versus asking me.

My post had nothing to do with discouraging you.  My post was to
answer what I thought was Matthew's question  and consolidate the
various arguments people have come into the conversation into one
place. That way instead of 40 emails going back and forth over various
aspects they could be affirmed that these are the points one side has,
and the other side could clarify or clean up the response.

At this point, I am done here.

Nie mój cyrk, nie moje małpy

>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Matthew Miller]

On Thu, Mar 30, 2017 at 07:48:34PM +0100, Tomasz Kłoczko wrote:
> I'm fully aware that proposing such widely spreading change I'm entering on
> some conflict/battle ground.
> I know that all long and/or complicated conflicts are possible to finish
> using only using two methods: by giving or taking away hope.
> Stephen you chose to discourage me .. noticed ;-P
> You must know something about me that I'm really hard nut and as long as
> you will be not giving me stricte technical/engineering arguments please
> expect that such argumentation will be crushed only on technical background
> using my exp, knowledge and/or thing which I've already done .. so I'm not
> using guessing like you :)
> Please stop using guessing :)

All those smiley faces not withstanding, this is not an acceptable form
of argumentation. You don't know whether the person you are replying to
is "guessing" or whether they actually have experience and expertise
which just happens to be different from yours. In fact, in this case, I
will guarantee you that it's absolutely true.

Rather than discounting experience that's different from yours in this
way, try to see what you might learn from it.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 30 March 2017 at 17:00, Stephen John Smoogen  wrote:

> 1) They are going to have 'non-upstream' patches for all their
> software.. which is just one more thing to keep up with every update.
>
2) Most of this software is not stuff they care about. It is branches
> on a tree for the only reason they packaged it up in the first place.
> So it is busy work from what they want.
>
3) This isn't the only rodeo they are putting this package in. So this
> patch set looks like a special snowflake patch they have to keep up
> with.
>

Majority (+95%) of the patches related to build, install and test suite
framework used by project is never changing.
/usr/bin/env changes are such changes because I've been able to observer
within +3 years across few thousands packages.
Some of those changes will be used as long as distribution will be actively
maintained because it is really hard sometimes to maintain such build,
install and test suite framework fulfilling all OSeses needs.
Sometimes it is not about those that some source maintainers are kind of
bab people.
Sometimes some people maintaining some publically available code are
earning money from maining such projects by offering paid support for such
software. In such cases it is nothing bad that such people do not care abut
people which are not giving then money using such software.

As those changes are trivial maintaining them takes really small fraction
of whole time necessary to upgrade package spec file between versions.
My personal observation says me that within last decade more than +60% of
such changes never been updated.


Sorry to say this but you are guessing and guessing you may have such
impression that above may be truth.
Reality is different.

I'm fully aware that proposing such widely spreading change I'm entering on
some conflict/battle ground.
I know that all long and/or complicated conflicts are possible to finish
using only using two methods: by giving or taking away hope.
Stephen you chose to discourage me .. noticed ;-P
You must know something about me that I'm really hard nut and as long as
you will be not giving me stricte technical/engineering arguments please
expect that such argumentation will be crushed only on technical background
using my exp, knowledge and/or thing which I've already done .. so I'm not
using guessing like you :)
Please stop using guessing :)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 30 March 2017 at 12:00, Michael Schwendt  wrote:

> True, and I haven't claimed the opposite. You need to slow down, IMO,
> as it seems you've misunderstood me completely. It's really just that
> whereas some packagers have removed /usr/bin/env from their packages,
> others have refused to do that, and neither the Review Guidelines nor
> the Packaging Guidelines contain anything about removing /usr/bin/env.
> In various reviews that would make it more difficult to convince package
> submitters, and some would argue endlessly about wanting to keep
> /usr/bin/env.
>

I see more and more issues related to FPG. And most discouraging is not
what is inside FPG because I can agree with most of the advices in this
document
Seem some packagers are using it almost blindly. And we are not talking
about few but something like almost majority.

Example. Few days ago I've submitted changes to slang to remove build and
package static libraries and couple of other minor fixes.
https://bugzilla.redhat.com/show_bug.cgi?id=1436909
Most of those changes so far have been refused and and for some reason
packager found even that in submitted patches I doing more than it is
described.
I've added as well after initial submission patch which removes using env
on calling slsh.
All those issues are some results of miscommunication and I'm not going to
blame anyone.

Seems problem will be here with one very minor thing about how to implement
Obsolete rule which should remove slang-static from the system.
This single line has been changes to versioned Obsolete rule.
My first reaction is written in the comment in this ticket.
After this I've started asking myself why it was changed this way. And I
found why ..
Because in FPG there is no point about how to add rules about permanent
remove of the package when like in case all static subpackages which I'm
going to introduce. In absence of such detail is used what is already
mentioned about using Obsolete to change name of the package.
OK. After I found that in this case it may be matter of miscommunication
 simple I've asked myself "so how it is with using it Obsoletes in other
Fedora specs?"
I was really surprised that ~95% of the Obsolete lines contains versions.
There are even more bizarre things here because in may specs it is possible
to find not fixed versions but versioning using %{version} and %{release}
macros.
100% of Obsolete rules about static packages obsoletion are with versions.
Some of them are with %{version} and %{release}.
Obviously it is wrong because if decision about remove permanently doesn't
matter which one version wa found decision not tolerating such package with
Fedora packages has been made and adding versions to Obsolete rule is
pointless .. "Roma locuta, causa finita".

Again so far please do not read above as blaming anyone like those people
Because my teachers always been telling me that "why? questions are most
important questions I've started digging deeper and I think that I found at
least two if not three possible explanations of above. I'm to shortly
observing Fedora forums and IRC channels to point on exact explanation as
correct, It is some possibility that it is possible to explain what I see
in other way.
Obviously using FPG has some roots in trying to formalise some changes.
Such pendulum of rules is moving between two points which are:
1) trying to stop some very stupid changes in some packages
2) trying to enforce spreading some exact well tested patters about how to
treat some resources in packages

So ..

Explanation 1
==
Somewhere on the past is was some number of bad cases with some changes in
packages that it was introduced some non written policy (not a guideline
but exactly *policy* which has stronger connotation than guideline) to not
do anything what is not described in FPG. Pressure on some unwise packagers
to use strictly using FPG was so strong that it blocked mids many other
packages to the point that they are refusing to implement some well
technically justified changes.
So here is result of some fright factor result.

Explanation 2
==
Some packages are inexperienced and not sure of own skills and because they
are not sure about some proposed changes using FPG is only possible to use
option.
So here we may have some kind of lack of confidence or experience/knowledge
factor.

Explanation 3
==
Some packagers are forgetting that G in FPG acronym stands for Guideline to
a Law or Policy.
Whatever what is written in Guideline will be very hard strictly use across
100% of packages because all rules of packaging even within limited space
of all possible correct spec files will take probably +10 times than
current size of FPG.
So here we may have some kind of lawyers or strict believers/followers
factor.

In case 1) I can easily point on many specs which are using things not
described in FPG. So at least some people are correctly understands that
"guideline" means set of advices which really 

Re: Mass issue: /usr/bin/env dependency

[Stephen John Smoogen]

5. If Fedora is a language for developers how am I supposed to develop
for other systems? And if I do this development why do I then have to
carry this patch for this one OS when if I did the development on
Ubuntu and put it in Universe I don't?

On 30 March 2017 at 12:10, Matthew Miller  wrote:
> On Thu, Mar 30, 2017 at 12:00:40PM -0400, Stephen John Smoogen wrote:
>> I think the thing that the problems packagers are looking at is the
>> following:
>>
>> 1) They are going to have 'non-upstream' patches for all their
>> software.. which is just one more thing to keep up with every update.
>> 2) Most of this software is not stuff they care about. It is branches
>> on a tree for the only reason they packaged it up in the first place.
>> So it is busy work from what they want.
>> 3) This isn't the only rodeo they are putting this package in. So this
>> patch set looks like a special snowflake patch they have to keep up
>> with.
>> 4) There is a difference between rules written down and rules in
>> action. While the rule has been this should be done, the fact that so
>> many packages have never done so and no one has pulled them for that..
>> says the real rule is it is not needed. Making a written rule an
>> action rule takes enforcement which always causes resistance.
>
> Good summary, and I definitely understand *these* problems. Just not
> the other one. :)
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Matthew Miller]

On Thu, Mar 30, 2017 at 12:00:40PM -0400, Stephen John Smoogen wrote:
> I think the thing that the problems packagers are looking at is the
> following:
> 
> 1) They are going to have 'non-upstream' patches for all their
> software.. which is just one more thing to keep up with every update.
> 2) Most of this software is not stuff they care about. It is branches
> on a tree for the only reason they packaged it up in the first place.
> So it is busy work from what they want.
> 3) This isn't the only rodeo they are putting this package in. So this
> patch set looks like a special snowflake patch they have to keep up
> with.
> 4) There is a difference between rules written down and rules in
> action. While the rule has been this should be done, the fact that so
> many packages have never done so and no one has pulled them for that..
> says the real rule is it is not needed. Making a written rule an
> action rule takes enforcement which always causes resistance.

Good summary, and I definitely understand *these* problems. Just not
the other one. :)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Stephen John Smoogen]

On 30 March 2017 at 11:44, Matthew Miller  wrote:
> On Thu, Mar 30, 2017 at 08:41:56AM -0400, Orcan Ogetbil wrote:
>> > These system executables are expecting to use the system python, and thus
>> > should use: #!/usr/bin/python."
>> I don't seem to get the above argument. Why do they not consider a
>> design where the system executables are expecting to use non-system
>> python when available?
>>
>> Suppose, as a developer, I need to test my software and scripts
>> against multiple versions of Python. What is the recommended way of
>> doing this? Symlinks? Alternatives?
>
> I don't understand the problem. I understand why one might want this
> for _user_ or _local_ software and scripts, but for _system_ software,
> Weird Problems can happen if you replace the interpreter with one which
> is not 100% compatible.
>
> If you know that your software will work for *all possible interpreters
> now and forever*, I can see using env in system packages, but otherwise
> it seems like asking for trouble.
>
> I guess if you always expect your software to be packaged in a larger
> construct where the environment is controlled (like part of a module
> going into a container), that could be useful too.

I think the thing that the problems packagers are looking at is the following:

1) They are going to have 'non-upstream' patches for all their
software.. which is just one more thing to keep up with every update.
2) Most of this software is not stuff they care about. It is branches
on a tree for the only reason they packaged it up in the first place.
So it is busy work from what they want.
3) This isn't the only rodeo they are putting this package in. So this
patch set looks like a special snowflake patch they have to keep up
with.
4) There is a difference between rules written down and rules in
action. While the rule has been this should be done, the fact that so
many packages have never done so and no one has pulled them for that..
says the real rule is it is not needed. Making a written rule an
action rule takes enforcement which always causes resistance.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Matthew Miller]

On Thu, Mar 30, 2017 at 08:41:56AM -0400, Orcan Ogetbil wrote:
> > These system executables are expecting to use the system python, and thus
> > should use: #!/usr/bin/python."
> I don't seem to get the above argument. Why do they not consider a
> design where the system executables are expecting to use non-system
> python when available?
> 
> Suppose, as a developer, I need to test my software and scripts
> against multiple versions of Python. What is the recommended way of
> doing this? Symlinks? Alternatives?

I don't understand the problem. I understand why one might want this
for _user_ or _local_ software and scripts, but for _system_ software,
Weird Problems can happen if you replace the interpreter with one which
is not 100% compatible.

If you know that your software will work for *all possible interpreters
now and forever*, I can see using env in system packages, but otherwise
it seems like asking for trouble.

I guess if you always expect your software to be packaged in a larger
construct where the environment is controlled (like part of a module
going into a container), that could be useful too.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Orcan Ogetbil]

On 29 March 2017 at 14:26, Tomasz Kłoczko wrote:
> ---
> Fedora ships numerous executables written in Python. Many of them contain
> the shebang line: #!/usr/bin/env python
>
> However, this makes it difficult to install alternative versions of Python
> on the system. If a user wishes e.g. to install python 3 on the system, and
> have a /usr/local/python in her PATH, this will break these executables.
>
> These system executables are expecting to use the system python, and thus
> should use: #!/usr/bin/python."
>
> Last line of this fragment says clearly that  #!/usr/bin/python should be
> used.

I don't seem to get the above argument. Why do they not consider a
design where the system executables are expecting to use non-system
python when available?

Suppose, as a developer, I need to test my software and scripts
against multiple versions of Python. What is the recommended way of
doing this? Symlinks? Alternatives?

By the way, I find the original post quite difficult to read. May I suggest:
https://en.wikipedia.org/wiki/Comma#Uses_in_English

Thanks,
Orcan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Michael Schwendt]

On Wed, 29 Mar 2017 19:26:31 +0100, Tomasz Kłoczko wrote:

> On 29 March 2017 at 17:04, Michael Schwendt wrote:
> 
> > It has been discussed several times, has met resistance and lead to
> > actions like
> >   https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSyst
> > emPython
> > but I don't remember any special section in the guidelines about it.
> >  
> 
> Quote from this page:
> 
> "Detailed Description
> ---
> Fedora ships numerous executables written in Python. Many of them contain
> the shebang line: #!/usr/bin/env python
> 
> However, this makes it difficult to install alternative versions of Python
> on the system. If a user wishes e.g. to install python 3 on the system, and
> have a /usr/local/python in her PATH, this will break these executables.
> 
> These system executables are expecting to use the system python, and thus
> should use: #!/usr/bin/python."
> 
> Last line of this fragment says clearly that  #!/usr/bin/python should be
> used.

True, and I haven't claimed the opposite. You need to slow down, IMO,
as it seems you've misunderstood me completely. It's really just that
whereas some packagers have removed /usr/bin/env from their packages,
others have refused to do that, and neither the Review Guidelines nor
the Packaging Guidelines contain anything about removing /usr/bin/env.
In various reviews that would make it more difficult to convince package
submitters, and some would argue endlessly about wanting to keep /usr/bin/env.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 29 March 2017 at 17:04, Michael Schwendt  wrote:

> It has been discussed several times, has met resistance and lead to
> actions like
>   https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSyst
> emPython
> but I don't remember any special section in the guidelines about it.
>

Quote from this page:

"Detailed Description
---
Fedora ships numerous executables written in Python. Many of them contain
the shebang line: #!/usr/bin/env python

However, this makes it difficult to install alternative versions of Python
on the system. If a user wishes e.g. to install python 3 on the system, and
have a /usr/local/python in her PATH, this will break these executables.

These system executables are expecting to use the system python, and thus
should use: #!/usr/bin/python."

Last line of this fragment says clearly that  #!/usr/bin/python should be
used.

In other cases .. rpm it is not IPS (Solaris packages management software)
which is able switch between for example python versions performing modules
dependencies verification, resolution and repointing on switching for
example between python 2.x an python 3.x allowing or not such operation as
some dependencies will be not broken.
As long as rpm has no such functionalities env is not a solution. It may be
only nothing more than workaround causing even more problems as side effect.

In other words IMO if someone has some impression that without extending
rpm in similar way as it is with IPS he.she may be right .. it is only
impression that it is true.
/
If env is used here in such transition scenarios (which so far I don't see
that it is the case) any python related issues  may start growing up as
someone will decide to put own version of the python in let's say
/usr/local/sbin not aware that because someone/something changed system
$PATH putting on the fron /usr/local/sbin all python scripts executed from
tty sessions will be no longer using python from packages but this one
installed manually.
He/she will be frustrated and in case of using some commercial support some
other guys will be witness of some "sex in the office" ("still I don't know
what but something is f*ing around!?!")

This is now very possible case as someone decided to add in /etc/profile:

pathmunge () {
case ":${PATH}:" in
*:"$1":*)
;;
*)
if [ "$2" = "after" ] ; then
PATH=$PATH:$1
else
PATH=$1:$PATH
fi
esac
}

[..]

# Path manipulation
if [ "$EUID" = "0" ]; then
pathmunge /usr/sbin
pathmunge /usr/local/sbin
else
pathmunge /usr/local/sbin after
pathmunge /usr/sbin after
fi

and by this by root and non root users on the front of the $PATH have
/usr/local/bin and/or /us/local/sbin

Only this is nothing more than asking for yet another dimension of troubles
with using env as in none of those "additional" paths are any resources
provided by distribution :->
Sometimes people are altering system $PATH by adding own scripts in
/etc/profile.d/
All those quite possible now bad cases could be avoided by dropping use env
in scripts provided by distro packages.

Just discovered that /root/.bash_profile from rootfiles adds "
PATH=$PATH:$HOME/bin" and /etc/skel/.bash_profile addes.
"PATH=$PATH:$HOME/.local/bin:$HOME/bin".
[mode=sarcasm]
These are really brilliant ideas!!!
Especially this part in /etc/profile about $PATH is .. mind blowing!!!
[/mode]
I would be really interested explanation what was behind all those $PATH
alteration.

>From https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

"/sbin  Essential system binaries, e.g., fsck, init, route."
"/usr/sbin Non-essential system binaries, e.g., daemons for various
network-services."

Hmm .. Fedora dropped some essential FHS compliance parts providing /sbin
content for non-root users on the $PATH??


Back to the env subject related to quoted from web page paragraph.

Nevertheless all cases which I've checked so fat are not about provide
possibility switching between python versions because only one of the
python packages provides provides python, python2 or python3. All those
cases are related to use python in fixed location as it is in Fedora and
most of the Linux distros.

$ rpm -ql python3 |grep bin
/usr/bin/pydoc3
/usr/bin/pydoc3.6
/usr/bin/python3
/usr/bin/python3.6
/usr/bin/python3.6m
/usr/bin/pyvenv
/usr/bin/pyvenv-3.6

$ rpm -ql python2 |grep bin
/usr/bin/pydoc
/usr/bin/pydoc2
/usr/bin/pydoc2.7
/usr/bin/python
/usr/bin/python2
/usr/bin/python2.7

BTW: pydoc it is more needed by someone who is just writing python code
than using it.
Probably it would be good to put pydoc in devel as pydoc can be started in
service mode providing over http documentation browsing services probably
such thing should not be by default installed on prod hosts (now is hard to
avoid this).
Am I right?

kloczek
-- 
Tomasz Kłoczko  | LinkedIn: *http://lnkd.in/FXPWxH *

Re: Mass issue: /usr/bin/env dependency

[Michael Schwendt]

On Wed, 29 Mar 2017 14:40:31 +0100, Tom Hughes wrote:

> On 29/03/17 14:16, Ralf Corsepius wrote:
> > On 03/29/2017 02:26 PM, Nikolai Kondrashov wrote:  
> >> I would say using env in the shebang line is useful. Particularly for
> >> portability. As a developer, I wouldn't like removing it from my
> >> programs.  
> >
> > FPC repeated discussed this and we decided to ban env, years ago.  
> 
> AFAIK it was was never made official though - it is still in draft:
> 
> https://fedoraproject.org/wiki/Script_Interpreters_(draft)

It has been discussed several times, has met resistance and lead to
actions like
  https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
but I don't remember any special section in the guidelines about it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Florian Weimer]

On 03/29/2017 02:26 PM, Nikolai Kondrashov wrote:

I would say using env in the shebang line is useful. Particularly for
portability. As a developer, I wouldn't like removing it from my programs.


Does it enable running packages unchanged against runtimes packaged as 
Software Collections?


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 29 March 2017 at 15:17, Nikolai Kondrashov 
wrote:

> > Getting rid of using env is much more legacy related things

> Most of them comes from the the time when Solaris and other flavours of
> the Unixes where the dominant Unix on the market.

Well, my concern was mostly


Don't worry about this. Today AIX and Solaris is more similar to the
typical Linux than it was ~20 years ago.
All those Unixes are around and they will be for next +two decades.
On introduce Solaris 10 was added set of deep changes allowing all admins
easier switching between different flavours of Ubnixes.
Some of those changes as well are migrating to the Linuxes as well.
Maintaining today growing set of similarities is matter of customers needs
that "making My(tm) Unix exceptional" in exactly this context.

> Many source trees maintainers which started own projects even recently
> coped base set of system detections where adding -lnsl to LIBS
> > was present. All such issues should be not fixed by something similar to
> plastering ..
>
> I agree, using -lnsl needlessly is bad. However, I suspect we might still
> need
> to keep it around for quite a while. Again, to help those programs that
> actually use it.
>

Who is proposing to remove NIS/NIS+/YP support from Fedora?
(Definitely not me .. and it is second time today here when someone is
interpreting my "can we please change it?" as "can we ban it?" 8-P )

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kłoczko]

On 29 March 2017 at 15:14, Vít Ondruch  wrote:

> I can't imagine how you want to convince most of the Ruby developers,
> who are typically using Mac with RVM or rbenv, to accept patch to change
> shebang from "/usr/bin/env ruby" to "/usr/bin/ruby". I suppose the
> situation is similar for Python with virtualenv ...
>

How?
Generally slowly and patience showing that proposed fix would allow to "[both]
the wolf be full, and the sheep safe (intact)"  :)
I'm 100% sure that necessary template solution for most of those those
issues is relatively easy.
Yes, it may be not obvious now how to do it but I'm sure that it will be
trivial.
No ruch .. as this fish is now exposed and close to the surface of the pond
it is easier to catch it :)

I'm sure that as issue will be presented in the way similar to what I've
done here some maintainer understanding that it is even some grain of risk
here solving it even by hardcoding fixed paths could be accepted by some
number of maintainers.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Nikolai Kondrashov]

On 03/29/2017 04:52 PM, Tomasz Kloczko wrote:
> On Wed, 2017-03-29 at 12:26 +, Nikolai Kondrashov wrote:
>> I would say using env in the shebang line is useful. Particularly for
>> portability. As a developer, I wouldn't like removing it from my programs.
> 
> Portability is not an issue at all here in this exact discussed case because 
> distribution resources as long as they are packaged into
> binary packages they are ALL *already ported resources*.
> You can provide 100% functional source code not depending on env and still 
> able to produce resources to install with fixed location of
> . This is not the rocket science.

Right. I misread your message and answered in a hurry.
I apologize for taking your time.

I thought you suggested /usr/bin/env use must be fixed in upstreams. I'm OK
with it being fixed on packaging, although I'm not particularly happy about
it.

>> Moreover, if your PATH is compromised, you're most likely screwed.
> 
> Still .. if $PATH will be compromised removing using env decreases risk here
> because removing using env attaches script to some fixed  path.

Yeah, it decreases risk, but not much.

>> I understand, that env use in scripts makes is inconvenient in some cases,
>> but I think that RPM build procedure and Fedora practices need to be fixed
>> instead.
> 
> So instead decreasing generally entropy you are proposing increase it .. by
> introduce kind of JFDI :)

Yeah, I was just trying to not increase it outside Fedora, but I realize now
it is not likely to be affected.

>> The number of packages using env in scripts alone shows that it is a
>> widespread and useful practice.
> 
> This is not about practice.
> Generally using env comes from the time when when installing additional 
> version of the  was only civilised way fulfilling
> some needs without changing distribution resources.
> Second typical past scenario was when distribution not been providing 
>  and users have been installing it manually on top
> of distribution in non arbitrary locations.
> In other words always evn was more workaround than RightSolution(tm) and now 
> it is part of the legacy which can be removed cleanly.
> 
> Using env it is more *legacy badge* which needs to be dropped best in source 
> code trees.
> Producing patches and submitting them to source code maintainers will help 
> get rid those issues.
> If you will have look on those packages affected by env you will find that 
> ~97-98% of all cases is related to prl and python.
> Committing today in source trees paths to those two interpreters as located 
> in /usr/bin will not hurt portability of such code on other
> Unixes as they already provides exactly the same versions of those 
> interpreters in the same locations as on typical Linux
> distributions.
> 
> Getting rid of using env is much more legacy related things.
> Most of them comes from the the time when Solaris and other flavours of the 
> Unixes where the dominant Unix on the market.

Well, my concern was mostly about interpreters in different locations on
different *nixes.

> There is much more such legacies still embedded in source trees which now can 
> be dropped,
> Example:
> 
> # dnf repoquery --whatrequires 'libnsl.so.1()(64bit)' \*.x86_64 | wc -l
> Last metadata expiration check: 1:19:13 ago on Wed Mar 29 12:36:31 2017 BST.
> 294
> 
> ATM in glibc libnsl provides almost only ABI/API used by NIS/YP/NIS+ NSS maps 
> related binaries.
> On Solaris the same library contains some base network sockets functions.
> Of cource today using on Linux libnsl by some packages does not means that 
> there are so many software is related to NIS/YP/NIS+ :)
> 
> Many source trees maintainers which started own projects even recently coped 
> base set of system detections where adding -lnsl to LIBS
> was present. All such issues should be not fixed by something similar to 
> plastering ..

I agree, using -lnsl needlessly is bad. However, I suspect we might still need
to keep it around for quite a while. Again, to help those programs that
actually use it.

Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Vít Ondruch]

Dne 29.3.2017 v 15:52 Tomasz Kloczko napsal(a):
> On Wed, 2017-03-29 at 12:26 +, Nikolai Kondrashov wrote:
>> I would say using env in the shebang line is useful. Particularly for
>> portability. As a developer, I wouldn't like removing it from my programs.
> Portability is not an issue at all here in this exact discussed case because 
> distribution resources as long as they are packaged into
> binary packages they are ALL *already ported resources*.
> You can provide 100% functional source code not depending on env and still 
> able to produce resources to install with fixed location of
> . This is not the rocket science.
>
>> Moreover, if your PATH is compromised, you're most likely screwed.
> Still .. if $PATH will be compromised removing using env decreases risk here 
> because removing using env attaches script to some fixed
>  path.
>
>> I understand, that env use in scripts makes is inconvenient in some cases,
>> but I think that RPM build procedure and Fedora practices need to be fixed
>> instead.
> So instead decreasing generally entropy you are proposing increase it .. by 
> introduce kind of JFDI :)
>
>> The number of packages using env in scripts alone shows that it is a
>> widespread and useful practice.
> This is not about practice.
> Generally using env comes from the time when when installing additional 
> version of the  was only civilised way fulfilling
> some needs without changing distribution resources.
> Second typical past scenario was when distribution not been providing 
>  and users have been installing it manually on top
> of distribution in non arbitrary locations.
> In other words always evn was more workaround than RightSolution(tm) and now 
> it is part of the legacy which can be removed cleanly.
>
> Using env it is more *legacy badge* which needs to be dropped best in source 
> code trees.
> Producing patches and submitting them to source code maintainers will help 
> get rid those issues.

I can't imagine how you want to convince most of the Ruby developers,
who are typically using Mac with RVM or rbenv, to accept patch to change
shebang from "/usr/bin/env ruby" to "/usr/bin/ruby". I suppose the
situation is similar for Python with virtualenv ...

Actually if you searched packages for /usr/bin/env, I'd love to know the
ration to packages with /usr/bin/ruby (in my case). And you can exclude
the packages where the shebang is already modified from upstream.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kloczko]

On Wed, 2017-03-29 at 14:40 +0100, Tom Hughes wrote:
> > FPC repeated discussed this and we decided to ban env, years ago.
> 
> AFAIK it was was never made official though - it is still in draft:
> 
> https://fedoraproject.org/wiki/Script_Interpreters_(draft)

As well my pointing on using env does not mean banning it :)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tomasz Kloczko]

On Wed, 2017-03-29 at 12:26 +, Nikolai Kondrashov wrote:
> I would say using env in the shebang line is useful. Particularly for
> portability. As a developer, I wouldn't like removing it from my programs.

Portability is not an issue at all here in this exact discussed case because 
distribution resources as long as they are packaged into
binary packages they are ALL *already ported resources*.
You can provide 100% functional source code not depending on env and still able 
to produce resources to install with fixed location of
. This is not the rocket science.

> Moreover, if your PATH is compromised, you're most likely screwed.

Still .. if $PATH will be compromised removing using env decreases risk here 
because removing using env attaches script to some fixed
 path.

> I understand, that env use in scripts makes is inconvenient in some cases,
> but I think that RPM build procedure and Fedora practices need to be fixed
> instead.

So instead decreasing generally entropy you are proposing increase it .. by 
introduce kind of JFDI :)

> The number of packages using env in scripts alone shows that it is a
> widespread and useful practice.

This is not about practice.
Generally using env comes from the time when when installing additional version 
of the  was only civilised way fulfilling
some needs without changing distribution resources.
Second typical past scenario was when distribution not been providing 
 and users have been installing it manually on top
of distribution in non arbitrary locations.
In other words always evn was more workaround than RightSolution(tm) and now it 
is part of the legacy which can be removed cleanly.

Using env it is more *legacy badge* which needs to be dropped best in source 
code trees.
Producing patches and submitting them to source code maintainers will help get 
rid those issues.
If you will have look on those packages affected by env you will find that 
~97-98% of all cases is related to prl and python.
Committing today in source trees paths to those two interpreters as located in 
/usr/bin will not hurt portability of such code on other
Unixes as they already provides exactly the same versions of those interpreters 
in the same locations as on typical Linux
distributions.

Getting rid of using env is much more legacy related things.
Most of them comes from the the time when Solaris and other flavours of the 
Unixes where the dominant Unix on the market.

There is much more such legacies still embedded in source trees which now can 
be dropped,
Example:

# dnf repoquery --whatrequires 'libnsl.so.1()(64bit)' \*.x86_64 | wc -l
Last metadata expiration check: 1:19:13 ago on Wed Mar 29 12:36:31 2017 BST.
294

ATM in glibc libnsl provides almost only ABI/API used by NIS/YP/NIS+ NSS maps 
related binaries.
On Solaris the same library contains some base network sockets functions.
Of cource today using on Linux libnsl by some packages does not means that 
there are so many software is related to NIS/YP/NIS+ :)

Many source trees maintainers which started own projects even recently coped 
base set of system detections where adding -lnsl to LIBS
was present. All such issues should be not fixed by something similar to 
plastering ..

kloczek
PS. Just added first env fixing patch in proposed slang changes removing build 
and use (by test suite) slang static libraries
https://bugzilla.redhat.com/show_bug.cgi?id=1436909
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Tom Hughes]

On 29/03/17 14:16, Ralf Corsepius wrote:

On 03/29/2017 02:26 PM, Nikolai Kondrashov wrote:

I would say using env in the shebang line is useful. Particularly for
portability. As a developer, I wouldn't like removing it from my
programs.


FPC repeated discussed this and we decided to ban env, years ago.


AFAIK it was was never made official though - it is still in draft:

https://fedoraproject.org/wiki/Script_Interpreters_(draft)

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Nikolai Kondrashov]

On 03/29/2017 04:16 PM, Ralf Corsepius wrote:
> On 03/29/2017 02:26 PM, Nikolai Kondrashov wrote:
>> I would say using env in the shebang line is useful. Particularly for
>> portability. As a developer, I wouldn't like removing it from my programs.
>
> FPC repeated discussed this and we decided to ban env, years ago.

Could you perhaps provide a link to that discussion? Thank you.

>> Moreover, if your PATH is compromised, you're most likely screwed.
>>
>> I understand, that env use in scripts makes is inconvenient in some cases,
>> but I think that RPM build procedure and Fedora practices need to be fixed
>> instead.
>>
>> The number of packages using env in scripts alone shows that it is a
>> widespread and useful practice.
>
> No. This observation only shows that some packagers haven't done their 
> homework.

Well, I would say those two observations are not contradictory.

Nick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Ralf Corsepius]

On 03/29/2017 02:26 PM, Nikolai Kondrashov wrote:

I would say using env in the shebang line is useful. Particularly for
portability. As a developer, I wouldn't like removing it from my programs.


FPC repeated discussed this and we decided to ban env, years ago.


Moreover, if your PATH is compromised, you're most likely screwed.

I understand, that env use in scripts makes is inconvenient in some cases,
but I think that RPM build procedure and Fedora practices need to be fixed
instead.

The number of packages using env in scripts alone shows that it is a
widespread and useful practice.


No. This observation only shows that some packagers haven't done their 
homework.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Remi Collet]

Hi,

Le 29/03/2017 à 14:08, Tomasz Kloczko a écrit :
> 
> There are several issues with /usr/bin/env dependencies and all those issues 
> are related to scripts which in script preamble are using
> "#!/usr/bin/env ":

For php tools (at least the ones I own), this is a deliberate packaging
choice, which allow to run these tools with Software Collections.

$ phpunit
... using default php...

$ module load php-71
$ phpunit
... using php 7.1...

etc

And I always take care to ensure the default interpreter is required
(via php-cli)


BTW; despite a rpmlint warning, there is nothing about this in
Guidelines (or I didn't find anything).

So, I don't plan to fix any listed package.


Remi.



P.S. also see
https://blog.remirepo.net/post/2016/04/16/My-PHP-Workstation
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass issue: /usr/bin/env dependency

[Nikolai Kondrashov]

I would say using env in the shebang line is useful. Particularly for
portability. As a developer, I wouldn't like removing it from my programs.

Moreover, if your PATH is compromised, you're most likely screwed.

I understand, that env use in scripts makes is inconvenient in some cases,
but I think that RPM build procedure and Fedora practices need to be fixed
instead.

The number of packages using env in scripts alone shows that it is a
widespread and useful practice.

Nick

P.S. My e-mail to the list wasn't accepted, saying I'm not a member. Why?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org