Patch for devel/apr1
Eygene Ryabinkin
rea at freebsd.org
Mon Feb 24 18:03:04 UTC 2014
It will be somewhat long letter filled with things that might be
considered as the personal insults. It isn't. I never meant to
offend anyone and I appreciate the work all people who read this are
doing.
Mon, Feb 24, 2014 at 05:45:09PM +0100, Mathieu Arnold wrote:
> +--On 24 février 2014 20:19:21 +0400 Eygene Ryabinkin <rea at freebsd.org>
> wrote:
> |> I've just committed a patch to bsd.options.mk[1] so that it tells
> |> you you are using an old way and should update.
> |
> | Well, while this can have its own merits, it is a way too many POLA
> | changes and sudden hickups (iconv in base, this change, ld's
> | --add-needed change) that make me to collide my head and the
> | table/wall.
>
> I would consider it POLA if we added a warning eight months ago and removed
> support seven months ago.
>
> You've had eight months to update, and now, I'm adding a warning telling
> you that you should update, I'm even giving you the correct way to do it.
Consider some J. Random User who even reads /usr/ports/UPDATING. Can he
notice that change even now? No, he can't. He should read mailing lists?
Perhaps, but he will just probably change the OS.
Half a year, you said? Who cares even if a personal letter will be
delivered to every user of FreeBSD along with a tart and striptease
girl. I am serious here: end users don't care about this. New
feature? Good, perhaps I'll use it. Broke my lovely old way of doing
things? The system is a piece of shit. It's that simple. It can
happen not on a single occasion, but rather be a death by thousands
paper cuts, but still: there is no shortage of OS nowadays. And you
know the current state of FreeBSD amongst them.
> | As the admin of the large pile of FreeBSD resources I should say that
> | it became terribly hard to upgrade ports when one uses source-based
> | approach with fine tuning. Sorry, can't help to mention all this.
>
> If you maintain a large pile of FreeBSD machines, you should really switch
> to binary packages. I know for $WORK I've gone that way, it's so much
> better to just run pkg upgrade, and get back a minute or two later with 200
> ports updated.
>
> If the stock binary packages don't meet your needs, install
> ports-mgmt/poudriere on a solid box and build your own packages.
That's, perhaps, a good advice given that current state of ports and
its future directions, but you're basically saying "ruin all the work
and adopted practices and move to the binary packaging you had
abandoned years ago for a good reason". I can do that; I even can let
my admins to cope with that, write and deploy new tools. But I am in
no wonder why FreeBSD loses its race: developers are constantly saying
"here is your new feature, forget the old ways". I am not against new
features, but I am against cutting old ways to do things when they can
be still supported (more on the "supported" below).
I have my own cons on having centralized building cluster for binary
packaging, most notable one will be a centralization that brings more
points of failure, but in this conversation I am trying to emphasize
the other aspect: constant stream of new features that eliminate the
old and proven ways to manage the system for no good from the
user/admin POV.
Mon, Feb 24, 2014 at 05:59:07PM +0100, Baptiste Daroussin wrote:
> On Mon, Feb 24, 2014 at 08:19:21PM +0400, Eygene Ryabinkin wrote:
> > Mon, Feb 24, 2014 at 04:43:06PM +0100, Mathieu Arnold wrote:
> > > Hum, there can be no simple fix, the reason it is not supported is that
> > > with that, you can break the port by forcing multiple options where only
> > > one should be enabled.
> >
> > It works for me with OPTIONS_SINGLE of mutt with
> > {{{
> > # Mutt
> > .if ${.CURDIR:M/usr/ports/mail/mutt}
> > BATCH=yes
> > WITH_SCREEN=yes
> > WITH_NCURSES=yes # SCREEN: single
> > WITH_SLANG=yes # SCREEN: single
> > WITH_COMPRESSED_FOLDERS=yes
> > WITHOUT_DEBUG=yes
> > WITHOUT_FLOCK=yes
> > WITH_GPGME=yes
> > WITHOUT_GREETING_PATCH=yes
> > WITHOUT_HTML=yes
> > WITH_ICONV=yes
> > WITHOUT_IDN=yes
> > WITH_IFDEF_PATCH=yes
> > WITHOUT_IMAP_HEADER_CACHE=yes
> > WITH_LOCALES_FIX=yes
> > WITH_MAILBOX_MANPAGES=yes
> > WITH_MAILDIR_HEADER_CACHE=yes
> > WITH_MAILDIR_MTIME_PATCH=yes
> > WITHOUT_NNTP=yes
> > WITHOUT_PARENT_CHILD_MATCH_PATCH=yes
> > WITH_QUOTE_PATCH=yes
> > WITH_REVERSE_REPLY_PATCH=yes
> > WITH_SASL=yes
> > WITHOUT_SGMLFORMAT=yes
> > WITHOUT_SIDEBAR_PATCH=yes
> > WITHOUT_SIGNATURE_MENU=yes
> > WITH_SMIME_OUTLOOK_COMPAT=yes
> > WITH_SMTP=yes
> > WITH_TOKYOCABINET=yes
> > WITHOUT_TRASH_PATCH=yes
> > WITHOUT_XML=yes
> > WITHOUT_ASPELL=yes
> > WITHOUT_ISPELL=yes
> > .endif
> > }}}
> > I have the proper error,
> > {{{
> > $ make
> > ====> You must select one and only one option from the SCREEN single
> > make: exec(exit) failed (No such file or directory)
> > *** Error code 1
> >
> > Stop.
> > }}}
> >
> > > I've just committed a patch to bsd.options.mk[1] so that it tells
> > > you you are using an old way and should update.
> >
> > Well, while this can have its own merits, it is a way too many POLA
> > changes and sudden hickups (iconv in base, this change, ld's
> > --add-needed change) that make me to collide my head and the
> > table/wall.
> >
>
> You cannot call POLA on something new OPTIONS_GROUP, OPTIONS_RADIO,
> OPTIONS_SINGLE, OPTIONS_MULTI are new the maintainer as decided to
> use the new interfaces because they are more convenient.
Itroduction of new OPTIONS_* have nothing to do with the WITH/WITHOUT
mechanism. Maintainer can decide to use whatever he wants, so as end
user/admin. These things are _completely_ orthogonal to each other.
> The old option framework as moved to OPTIONS_DEFINE and thus we
> maintain compatibility for this change (hence the WITH/WITHOUT thing
> working properly with OPTIONS_DEFINE options).
I, as user/admin, don't care about the guts of the ports framework; thus
for me it is POLA violation. The undocumented (at most, poorly-documented)
one.
> All you used to manually do via .if ${.CURDIR...} can be intrument a reliable
> way with the new option framework directly and it will work with all OPTIONS_*
> things:
>
> mail_mutt_SET= TOKYOCABINET GPGME
> mail_mutt_UNSET= ASPELL ISPELL
>
> OPTIONS_SET will make it global and it can be overwritten by the specifion:
> <cat>_<port>_SET
>
> same goes for unset.
"Reliable" isn't a good word here: my way of checking .CURDIR is as
reliable as yours (and has an added bonus of zero thinking about if I
should use <port> or UNIQUE_NAME as the second component of
_SET/_UNSET). This has nothing to do with reliability.
"Work with all OPTIONS_* things": well, that's what we're talking
about. I see zero difference between _SET/_UNSET and WITH_/WITHOUT_,
they are isomorphical in mathematical sense, I can transform one into
another without any ambiguity. What if you'll have two options from
_SINGLE set via _SET? That doesn't different from having two these
options set via WITH_.
From the usability POV, having each option on a different line greatly
helps when one uses vi (or, may be, emacs): to change from set to
unset you just change WITH -> WITHOUT and vice-versa. Having a range
of words on a two lines, makes set -> unset change to involve cut and
paste, twice more operations.
Such things may be regarded as "minor", but devil is in the details,
as usual. And some very subtle details can make people to be much
more productive or to feel uncomfortable and embarrassed.
Yes, WITH_/WITHOUT_ may add some more code to the bsd.options.mk and
will add some hurdle for its maintainers. But users won't see that
(may see if the code to support the old knows will be that horrible
and creepy that it will break everything around; but we know how to
engineer and produce the good code, aren't we?).
Probably, the code for handling WITH_/WITHOUT_ will be messy, though I
see no problems in transforming WITH_/WITHOUT_ into _SET/_UNSET that
you should handle anyway. That's just a transformation that involves
the single additional knowledge: list of all options that can be
tweaked for the port. All logics will be in _SET/_UNSET handling.
Guys, I am just trying to emphasize that FreeBSD is for its users.
The user base is already small and is ceasing. All such occurences of
changes that are not considered as POLA violations by portmgr and
committers could be considered as such by end users. Less end-users
== less testing and less demand for the system itself. I love FreeBSD
with my whole soul, but it started to drive me mad more and more. For
the god's sake, please, think about all your changes and removal of
old "cruft" from the point of view of simple admin whose life is
already not easy at all.
I think that I had said enough already and this may end up as the
thread that wastes time of everyone involved, but I am really deeply
concerned with the changes that were made over the past years. Many
people love FreeBSD not only because it has great features and serves
as the reliable platform, but because it has familiar environment and
practices that change very slowly and gradually. I know that even if
I will face something like 4.11, I will be in familiar environment.
And I know that if I'll include compatibility shims for 4.x, I will be
even able to upgrade the system without breaking binary compatibility
for the most parts of the system. And that's I and many other people
really appreciate, so don't ruin that. Please.
--
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 358 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-apache/attachments/20140224/b71d755e/attachment.sig>
More information about the freebsd-apache
mailing list