Fw: RE: pkgng default release schedule (s/ABI/API/g ...typo)

[Jeffrey Bouquet]

s/ABI/API/g   Sorry! 



--- On Fri, 8/24/12, Jeffrey Bouquet <jeffreybouquet at yahoo.com> wrote:

> From: Jeffrey Bouquet <jeffreybouquet at yahoo.com>
> Subject: RE: pkgng default release schedule (contd...)
> To: "Chris Rees" <utisoft at gmail.com>
> Date: Friday, August 24, 2012, 1:28 PM
> Comments below. I've no idea how to
> fix the quoting system so I'll try to do it manually, Maybe
> in a few weeks... it is webmail and its-all-text seems no to
> function at the moment.
> 
> --- On Fri, 8/24/12, Chris Rees <utisoft at gmail.com>
> wrote:
> 
> From: Chris Rees <utisoft at gmail.com>
> Subject: RE: pkgng default release schedule (contd...)
> To: "Jeffrey Bouquet" <jeffreybouquet at yahoo.com>
> Date: Friday, August 24, 2012, 10:57 AM
> 
> 
> 
> On 24 Aug 2012 15:37, "Jeffrey Bouquet" <jeffreybouquet at yahoo.com>
> wrote:
> 
> >
> 
> > Comments inline below...
> 
> >
> 
> > --- On Fri, 8/24/12, Chris Rees <utisoft at gmail.com>
> wrote:
> 
> >>
> 
> >>
> 
> >> From: Chris Rees <utisoft at gmail.com>
> 
> >> Subject: RE: pkgng default release schedule
> (contd...)
> 
> >> To: "Jeffrey Bouquet" <jeffreybouquet at yahoo.com>
> 
> >> Cc: "FreeBSD Mailing List" <freebsd-ports at freebsd.org>,
> "freebsd-current" <freebsd-current at freebsd.org>
> 
> 
> >> Date: Friday, August 24, 2012, 4:37 AM
> 
> >>
> 
> >>
> 
> >> On 24 Aug 2012 11:08, "Jeffrey Bouquet" <jeffreybouquet at yahoo.com>
> >>wrote:
> 
> >> >
> 
> >> > A few more reasons (unless I have not seen
> some relevant >>documentation to the contrary) to not
> mandate pkgng as the default...
> 
> >>
> 
> >>
> 
> >> Why don't you phrase this as "How can one ..." so
> you sound less >>negative?
> 
> >>
> 
> >Please fix your mailer's quoting.
> It is webmail. Sorry. I am fixing part of it as I go along
> but I've no idea if it is making it worse...
> 
> 
> 
> >> I am unequivocably opposed (reasoning below
> included, after I wrote >>this paragraph; ) to pkg
> mandated as the default, until convinced
> 
> >>
> 
> >> otherwise, and trying to sound nicer, by making the
> sentences >>shorter.  If that is
> 
> >>
> 
> >> stubborness-from-ignorance, I  sincerely
> apologize, in advance.  But >>I see no one else
> 
> >>
> 
> >> vocalizing opposition at the moment... vs those in
> favor, and am >>simply in my
> 
> >>
> 
> >> view voicing arguments to delay the not-inevitable
> deprecation of >>/var/db/pkg...
> 
> >Possibly because your attitude as I mention above makes
> people think 
> >you're trolling.
> 
> I am dismayed by the thought that the package management
> system is
> broken.  We have the Makefile directories (starting
> point) /var/db/pkg
> directories (registration feature) portmaster/portmanager/
> custom .sh/
> portupgrade (automation feature) and the installed binaries
> (end point).
> Pkg introduces an ABI making
> portmaster/portmanager/portupgrade/to-be-portupgrades/.sh
> costlier to implement in time, ABI experience, 
> and maybe buggier.  Meanwhile, the registration feature
> (present in
> BSD, absent AFAIK in most Linux, abstracted in Windows),
> would be
> abstracted in BSD also.  
> 
> Suppose I rightly viewed that the ports tree was not working
> well
> enough for the majority of users.
> 
> There is a new tool, portsnap-textonly (psto)
> Its use is easy!
> psto view makefile editors nano
> psto configure editors nano
> psto view pkgplist editors nano
> psto view editors
> 
> I'm fully justified in putting it somewhere (a port.)
> It is only when I remove the actual ports tree to a
> xml-based or
> sql-based repository, that I begin to de-minimalistic
> de-potentially-better 
> Freebsd, and fork it to something that only may serve better
> a subset
> (however large) of its users. Even if I obtain the
> majority opinion that it is expedient, and
> even if it *is* actually expedient for the
> majority, I'd maybe want to quell the
> concerns of those very reluctant to pursue the paradigm
> shift that
> it is *not* in their best interests... or do more coding
> beforehand
> to compensate for the impact it may have upon their use of
> the operating system. 
> 
> 
> 
> 
> 
> 
> >> Certainly not trying to "just complain" for the
> sake of impeding >progress. 
> 
> >>
> 
> >> > Nowadays, one can save time by installing two
> ports which >officially or unofficially conflict, and
> have /var/db/pkg entries for >both, and even
> 
> >> > local workarounds (for instance, moving the
> duplicate binary >elsewhere before the second install)
> (Perchance removing the line in >the Makefile).
> 
> >>
> 
> >> Currently you can still do this, at least until
> STAGEDIR.
> 
> 
> 
> >>
> 
> >>
> 
> >> STAGEDIR? 
> >Not of concern at the moment, but it's in the FreeBSD
> wiki if you're >interested.
> Thank you for the information.
> >>
> 
> >> > A failed "make install (register)", one can
> check the /var/db/pkg/ >>directory(ies) to double
> check visually to what extent it did NOT >>fail.
> 
> >> > Similarly for a failed "make deinstall
> (unregister)"...
> 
> >>
> 
> >>
> 
> >> The error messages are perfectly clear.
> 
> >>
> 
> >> "The error messages are perfectly clear", yes, once
> double-checked >>against
> 
> >>
> 
> >> the directories in /var/db/pkg to make them
> less-terse.  If you mean >>pkg's 
> 
> >>
> 
> >> error messages, maybe *this* trepidation is from
> inexperience with >>pkg.
> See below.
> >>
> 
> >> > pkgdb -F to fixup stale dependencies and
> resolve dependency >>information.
> 
> >>
> 
> >>
> 
> >> Unnecessary with pkgng.
> 
> I'll take your word for it.  Thanks for the
> information. Howsoever, I've
> encountered stale dependencies with pkgdb -F after
> portmaster had
> fixed them up, so I am a little skeptical.
> 
> >>
> 
> >> Okay, I am unaware.
> 
> >Let me say this once more.
> >You have no right to complain about something until
> you've properly >tested it.  
> 
> I am not trying to complain about pkg(ng).  I am trying
> to dissuade
> the deprecation of /var/db/pkg/ as a plain-text hook into
> the 
> registration of ports/packages.  
> 
> There is no way I can properly test pkg and a deprecated
> /var/db/pkg
>  without more time and effort.  If you mean to say I
> should first install pkg fully on a machine and compare the
> 
> result to what I am doing now, I decided a few hours ago to
> do just
> that.  However, I've a lot of other stuff to do so it
> is not a
> priority.  If you mean to say I should delay stuff like
> this posting
> until I've tested further, I'll apologize here and
> now.  But it is
> easier and potentially more informative to others not
> decided, in
> my humble opinion, to read these views, if I state them
> politely 
> enough, than for me to write them down as a draft to post
> later.
> Maybe I will benefit by someone refuting them to my
> satisfaction,
> and saving you the effort of another reply.
> 
> 
>   
> 
> 
> >You will find that most of the scripts you currently use
> are to >compensate for brokenness in pkg_install and are
> no longer necessary.  
> 
> Most of the scripts I use are to upgrade, I've way too many
> ports
> installed to ever use the pkg_install command without a
> front end.
> The only ones I usually use are pkgdb -F and pkgdb -u and 
> portmaster -d -B -P -i -g ...  and the shell does most
> of the
> heavyweight work, as I save history across reboots. 
> The only
> breakage I am aware of are the usual ones, ports waiting to
> be
> fixed, conflicts, clang vs gcc, difficultes in fetching
> should
> it be an https://, etc.
> 
> 
> 
> > Scripting your way around bad design decisions is  not
> a way to run >an OS.
> Where is the bad design decision specifically?  I view
> an ABI into the
> plain-text port registration as a cure worse than the
> disease for
> the majority of cases.  I see Good Design specifics...
> portmaster
> for example.   I can run several in several
> xterms at once and they
> hardly ever collide...
> 
> 
> >> > A proven method in the portmaster manpage to
> reinstall all ports.
> 
> >>
> 
> >> You want to talk to the portmaster author about
> that.
> 
> >>
> 
> >> I never use the procedure, I've too many ports. 
> But others may be >>interested.
> >OK, please sort out your own views, then start worrying
> about other >people.
> Again, I've tried to state them nicely above, and put forth
> a few
> reasons why I am stating them now rather than later. 
> 
> >> *Anything* that circumvents  portmaster's
> fine-grained updating of >>the 
> 
> >>
> 
> >> each-port-its-own-database-directory-in-var-db-pkg,
> which is  a >>great help
> 
> >>
> 
> >> to myself daily, is in my view, unwarranted,
> untimely, bloat, >>contrary to the
> 
> >>
> 
> >> keep-it-simple port-upgrade tools "fixing it when
> it breaks" >>methodologies that
> 
> >>
> 
> >> exist at the present time, etc. 
> 
> >You mean, let's cobble together yet more hacks and
> continue to have a >package management system that is
> fifteen years out of date?
> I view portmaster, used above, as
> cutting-edge.   If the /var/db/pkg
> flat-file is out-of-date vs an ABI into an equivalent, 
> I see that
> as a fork away from minimalism, and as a disservice to
> ground-up
> based port-management tools.  
> If you are trying to say that the pkg based
> port-registration will
> work less-as-a-hack, than portmaster and shell scripting, it
> could
> be that I may switch to that view after testing, in which
> case I
> am fully too dismissive of pkg's potential.  But in my
> real-world
> experience so far, I view it as only a remote possibility,
> since
> it is not the day-to-day stuff I view as paramount, but the
> 
> recourses one has upon unexpected failures when rebuilding,
> say,
> perl from one version to another.  I've no reports of
> someone 
> attempting that with pkg so far...
> 
> 
> >I'm sorry that you enjoy messing with these files and
> are not going to >be able to do it in future.  The hard
> fact is that the people who do >the work in bringing you
> ports are sick of the inadequacies of the >current
> system, and are improving it.
> 
> Statement taken as an opinion unless specifically elaborated
> upon... I kind of have *fun* doing a 
> cat ffil_0812 | grep p5 | awk '{print $1}' | xargs -J %
> portmaster -d -B -P -i -g --update-if-newer % 
> ...typing only a few characters in it (from history), rinse,
> repeating
> for /devel/, /ftp/ ... etc... whereas before portmaster
> existed,
> portupgrade would upon the lower-power machines monopolize
> the CPU, etc
> since I can *automate* it at a machine I am not physically
> at during most of the several hours...  I see that as a
> not-inadequacy... it
> is, again, the command-line (non-abi) hook into the
> registration details
> that speeds (here) fix of breakages.  So maybe define
> inadequacy 
> more explicitly?
> 
> >Do some research and try it out.  You'll be amazed.
> 
> As I mentioned, I may be able to install it on one
> machine.  But 
> I am very pessimistic that its abstraction layer will be
> compensated for by any more-than-empirical improvement...
> Thanks
> for the optimism though.
> 
> 
> 
> >Chris
> 
>