Date: Sat, 5 Oct 2013 19:08:23 +0800 From: Buganini <buganini@gmail.com> Cc: Ports FreeBSD <freebsd-ports@freebsd.org> Subject: Re: [HEADSUP] Staging, packaging and more Message-ID: <CAC_-zwcKT0LpAPM6sYXA72Uu3x2cdVjRZ_=11UqJePMoA2YFbA@mail.gmail.com> In-Reply-To: <1380970300.26125.1.camel@mp> References: <20131003084814.GB99713@ithaqua.etoilebsd.net> <524D6059.2000700@FreeBSD.org> <524DD120.4000701@freebsd.org> <20131003203501.GA1371@medusa.sysfault.org> <CAGwOe2Ye2MLz3QpyMW3wyN9ew%2BiNnTETS1oOi_%2B8dPehUcWa0w@mail.gmail.com> <20131004061833.GA1367@medusa.sysfault.org> <20131004063259.GC72453@ithaqua.etoilebsd.net> <524E679B.9010103@infracaninophile.co.uk> <20131004070503.GF72453@ithaqua.etoilebsd.net> <524EB31C.6060102@quip.cz> <20131004132945.GL72453@ithaqua.etoilebsd.net> <524FE297.3030705@quip.cz> <1380970300.26125.1.camel@mp>
next in thread | previous in thread | raw e-mail | index | archive | help
Is it possible to eliminate the pain to maintain make-config
switchable plist entries?
Maybe with a AUTO_PLIST=yes or something like that, firstly install
everything to ${STAGEDIR}${PREFIX} then move everything to ${PREIX}?
this is similar to homebrew, except for that homebrew ln -s everything
instead of moving them.
2013/10/5 Mathias Picker <Mathias.Picker@virtual-earth.de>:
> Am Samstag, den 05.10.2013, 11:57 +0200 schrieb Miroslav Lachman:
>>
>> Baptiste Daroussin wrote:
>> > On Fri, Oct 04, 2013 at 02:22:52PM +0200, Miroslav Lachman wrote:
>> >> Baptiste Daroussin wrote:
>> >>> On Fri, Oct 04, 2013 at 08:00:43AM +0100, Matthew Seaman wrote:
>> >>>> On 04/10/2013 07:32, Baptiste Daroussin wrote:
>> >>>>> On the other ends, that makes the package fat for embedded systems, that also
>> >>>>> makes some arbitrary runtime conflicts between packages (because they both
>> >>>>> provide the same symlink on the .so, while we could live with 2 version at
>> >>>>> runtime), that leads to tons of potential issue while building locally, and
>> >>>>> that makes having sometime insane issues with dependency tracking. Why having
>> >>>>> .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc.
>> >>>>>
>> >>>>> Personnaly I do have no strong opinion in one or another direction. Should we be
>> >>>>> nicer with developers? with end users? with embedded world? That is the question
>> >>>>> to face to decide if -devel packages is where we want to go or not.
>> >>>>
>> >>>> Can't we have the best of both worlds?
>> >>>>
>> >>>> We're already planning on creating sub-packages for eg. docs and
>> >>>> examples. The default will be to install docs etc. sub-packages
>> >>>> automatically unless the user opts out in some way. I imagine there
>> >>>> will be a global switch somewhere -- in pkg.conf or similar[*].
>> >>>>
>> >>>> Couldn't we work devel packages in the same way? Install by default
>> >>>> alongside the main package unless explicitly requested not to.
>> >>>>
>> >>>> I think having the capability to selectively install parts of packages
>> >>>> like this is important and useful functionality and something that will
>> >>>> be indispensible for eg. embedded platforms. But not an option that the
>> >>>> vast majority of ordinary users will need to exercise.
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Matthew
>> >>>>
>> >>>> [*] The precise mechanism for choosing which sub-package bits to install
>> >>>> has not yet been written. If anyone has any bright ideas about how this
>> >>>> should all work, then I'd be interested to hear them.
>> >>>>
>> >>>
>> >>> That is another possiblity, I do prefer Erwin's idea about the -full, but this
>> >>> also makes a lot of sense.
>> >>
>> >> I really like the current state with full packages. Disk space is cheap,
>> >> full packages is default for whole FreeBSD existence and it is easy to
>> >> maintain the system with it. If I want portA and portB, I just install
>> >> portA and portB and if I want to see installed ports, I see two ports
>> >> installed and not a bunch of lines like:
>> >> portA-bin
>> >> portA-doc
>> >> portA-dev
>> >> portB-bin
>> >> portB-doc
>> >> portB-dev
>> >>
>> >> When I need to update those ports, I will update two ports, not six or
>> >> more ports / sub ports.
>> >>
>> >> Embedded systems are corner case, where many things need to be tweaked
>> >> anyway.
>> >>
>> >> So I like the idea of default full packages with possibility to
>> >> optionally select and install sub parts for those who really need the
>> >> fine grained list of packages.
>> >
>> > That is because you keep thinking you have to build those ports yourself, we are
>> > here speaking of binary packages.
>>
>> I don't think it's about building ports. It's about the list of what I
>> need to have installed and maintained on our systems. And with this
>> split to more packages, then the list will grow and tracking of changes
>> and dependencies will become hell like on Linux distributions.
>
> +1
>
> Mathias
>
>>
>> Miroslav Lachman
>> _______________________________________________
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
>
>
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAC_-zwcKT0LpAPM6sYXA72Uu3x2cdVjRZ_=11UqJePMoA2YFbA>