[HEADSUP] Staging, packaging and more

Tue Oct 8 08:05:55 UTC 2013

+1

Jov
blog: http:amutu.com/blog <http://amutu.com/blog>


2013/10/8 Mathias Picker <Mathias.Picker at virtual-earth.de>

>
>
>
>
> Pascal Schmid <pascal at lechindianer.de> schrieb:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On 10/06/2013 07:21 PM, Bernhard Fröhlich wrote:
> >> On Sun, Oct 6, 2013 at 2:20 PM, Ulrich Spörlein <uqs at freebsd.org>
> >wrote:
> >>> 2013/10/4 Bryan Drewery <bryan at shatow.net>:
> >>>> On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote:
> >>>>> On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote:
> >>>>>> On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin
> >wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Please no devel packages.
> >>>>>>>>>>
> >>>>>>>>>> Seconded.
> >>>>>>>>>
> >>>>>>>>> What's wrong with devel packages?
> >>>>>>>>
> >>>>>>>> It complicates things for developers and custom software on
> >FreeBSD. The typical
> >>>>>>>> situation that I see on most Linux platforms is a lot of
> >confusion by people, why
> >>>>>>>> their custom software XYZ does not properly build - the most
> >common answer: they
> >>>>>>>> forgot to install a tremendous amount of dev packages,
> >containing headers, build
> >>>>>>>> tools and whatnot. On FreeBSD, you can rely on the fact that if
> >you installed e.g.
> >>>>>>>> libGL, you can start building your own GL applications without
> >the need to install
> >>>>>>>> several libGL-dev, libX11-dev, ... packages first. This is
> >something, which I
> >>>>>>>> personally see as a big plus of the FreeBSD ports system and
> >which makes FreeBSD
> >>>>>>>> attractive as a development platform.
> >>>>>>>>
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>
> >>>>>> If we chose to go down that path, at least we should chose a
> >different name as we've
> >>>>>> used the -devel suffix for many years for developmental versions.
> >>>>>>
> >>>>>> I must agree that it is one of the things high on my list of
> >things that irritate me
> >>>>>> with several Linux distributions but I can see the point for for
> >embedded systems as
> >>>>>> well.  But can't we have both?  Create three packages, a default
> >full package and split
> >>>>>> packages of -bin, -lib, and even -doc.  My first though twas to
> >make the full package
> >>>>>> a meta-package that would install the split packages in the
> >background, but that would
> >>>>>> probably be confusing for users at the end of the day, so rather
> >just have it be a real
> >>>>>> package.
> >>>>>>
> >>>>> I do like that idea very much, and it is easily doable with stage
> >:)
> >>>>
> >>>> +1 to splitting packages for embedded usage.
> >>>
> >>> -1 for the split, as it will not fix anybody's problem.
> >>>
> >>> On regular machines, disk space is cheap and having to install more
> >packages is just annoying
> >>> to users. Think of the time wasted that people are told to apt-get
> >libfoo-dev before they can
> >>> build anything from github, or similar.
> >>>
> >>> If you actually *are* space constricted on your tiny embedded
> >machine, what the fuck are you
> >>> doing with the sqlite database and all the metadata about
> >ports/packages anyway? Just rm
> >>> /usr/include and /usr/share/doc, /usr/share/man, etc. when building
> >your disk image. But you
> >>> are doing that already anyway, so this solves no actual problem for
> >you.
> >>>
> >>> My two cents Uli
> >>
> >> I also don't see why we need to optimize our packages for an embedded
> >environment that is
> >> usually very customized. Wouldn't it make more sense to provide some
> >proper port / packaging
> >> options/flags that help to optimize size of the packages without
> >touching header files? People
> >> could use that flags and poudriere to build their packages together
> >with all their other
> >> compiler flags and cpu optimisations.
> >>
> >
> >+1
> >
> >As far as I can see Daniel Nebdal's approach ("WITH_DEV_FILES" flag,
> >and defaulting to "yes")
> >sounds promising.
>
> +1
>
> This doesn't change things in the standard case and follows existing
> patterns, so I like it, too.
>
> Mathias
>
> >
> >Pascal
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v2.0.21 (GNU/Linux)
> >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >iQIcBAEBAgAGBQJSUZ9hAAoJEAWefonBOgAfDlUP/3117hVdZ6WhrygIGnctSb49
> >V+i0SggAFxXuvFFYlkjexrWFpjMPN2H7vBtR9DVbLNwqb4En+mVj/LVY1ejS9TAQ
> >gj/nKlK6HNdVQWQD8qLfzFUAzWwnSBco/rIOiGkOrHuvFSUCTV5gPehoJ+Vg8Qnz
> >dyUp5SByePNpY1MGMTJZh9gKWJFtTe8DcanDBCVL65rZf/eOVPyiMwlQK+Fy2AQj
> >OQgJxhkWJzvl5V9THsMGiSCzJ+9EMoC620F9WEs3MvO0Ky2zIercFJ2bDaks6CXn
> >arNTsqTT1zI0sZNGNQMrnxYtQPgV3oCEAggj4ZOG0FkhmBkxWNOPUyahBUE/V8ds
> >tvLvugzVzqeaIJWg3IKDNEfGGh0ZnAMhUakUHyJPDhuCLgb498uwElesmgaSvlky
> >eotS4cWGVp2lquuf/xPRRl82K4ciozZi3mttRmrfoznK69p1HJbepCn9maIhFkii
> >WqLTjKVkeZ778is8mw8dom/Qb8OEj+XR6Vetq7cLg4Is//zieKzSvMWm7QrW1dAI
> >zohAjP+lMP5d3TEmeVqvSZhQ9ticzqGGaW4U7zxxRZ0Y/zxkBwe3cIBEpjTpnW9p
> >/a0DJ3JodVBo79N2JheIqweCK9RPn8rOK5HxujnWcJ3jbQAgCxOdLd9iyN6IxOjI
> >3pHI9pO++Am9ReFvL/Uy
> >=qm+q
> >-----END PGP SIGNATURE-----
> >_______________________________________________
> >freebsd-ports at freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >To unsubscribe, send any mail to
> >"freebsd-ports-unsubscribe at freebsd.org"
>
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>