On Fri, May 29, 2015 at 04:16:18PM -0400, Lennart Sorensen wrote:
> On Thu, May 28, 2015 at 07:32:26PM +0200, Gilles Chanteperdrix wrote:
> > As I said in the next mail, this is ridiculous. First a few headers
> > and a .pc file do not occupy that much room, I mean come on, people
> > have tera bytes disks now, and what does a Debian occupy with all
> > the packages installed 100 GiB ? And second the Debian system is
> > spending way much more space elsewhere with its package with all
> > options enabled that get a lot of stuff installed on your system
> > that you actually do not need. Look at libav dependencies for
> > instance. libav can be configured to have no external dependencies
> > and this is generally sufficient for common use like watching
> > videos. In addition to that, there are packages that you do not need
> > or want, that will cause apt to uninstall half the distribution if
> > you remove them, so, you have to keep them, and they are more than
> > just a few headers and a .pc file.
>
> We ship Debian on systems with 512MB of flash. Not everything is a
> desktop or a server. We like how Debian splits things, it is very
> convinient.
Once again, a few headers files is not going a problem. And I have
run root filesystems on 6MB flashes, Debian can not do that. So,
obviously, Debian pretends to do something that it can not do
completely. However, on a developer desktop, this makes things
uselessly painful. I run my distribution on a desktop, I do not care
what it does for other configurations. And on other configurations I
certainly would not use this distribution either, because of its
tendency to embark things on the filesystem I do not need and make
them unavoidable through false dependencies. So, I maintain this
over splitting of packages is ridiculous. The Linux foundation chose
yocto as the embedded distribution, not Debian.
>
> > "non-free Free Software Foundation documentation" sounds like a
> > cheap oxymoron does not it? And does not Debian have a directory
> > named "non-free" in its repository for this case? From a user-space
> > experience point of view, this was a frustrating change. That and
> > the gratuitous move of /usr/doc to /usr/share/doc, but that was a
> > long time ago.
>
> That was a long time ago. And the FSF making such a blunder is odd,
> but they did it, not Debian.
The point remains: Debian had a non-free directory to move the
packages to.
>
> > Well, I do not seem to have the problem right now, otherwise I would
> > have sent a screenshot. But I assure you I had it at some point.
> > Maybe it depends on some static IP range. But the error message made
> > it clear that your access was denied because you were using an
> > anonymous VPN service. Maybe the problem was fixed in the mean time.
>
> I wonder if they came up with a better way to prevent spammers messing
> with the wiki.
The Xenomai project had a wiki some time ago, and had spamming
issues too. We never resorted to something as stupid as blocking IP
address ranges to avoid spam.
> And last I checked it looked like slackware had been dead for a couple
> of years, which would make it even more stale than Debian stable.
Debian stable is also not released often (that is a euphemism).
I can give details on that. I installed Slackware 14.1, which had
more recent packages than Debian wheezy (this was before the jessie
release, obviously). And Slackware has a repository where volunteers
package upstream packages themselves and provide the build script,
and:
- the versions of these packages are current, and if they are not,
trying a more recent version is easy enough;
- the packages are the verbatim upstream packages, with much less
patches than the Debian distribution;
- if such package configure script has some
optional dependencies, you can usually choose whether you compile
the package to use that dependency, and if you can't, again,
modifying the build script is easy enough.
>
> > > often even in the upstream code in that case.
> >
> > From my point of view, a Debian package maintainer is responsible
> > for the Debian package quality. So, if he can not reach that quality
> > because the upstream code does not have a high enough quality, he
> > should not package it. Packaging low quality software without fixing
> > the quality issue is a bad service to the user. Again, a frustrating
> > experience from the end-user point of view.
>
> Well if people want the code even in the state it is in, it can be
> packaged. Perhaps Ubuntu's concept of having core packages, and then
> optional repositories of lower quality software makes sense there.
My two finals candidates, Slackware and archlinux do that too. That
is way more honest than calling a distribution "Debian stable" and
have it contain buggy packages.
>
> > For some software (mostly server/infrastructure software) a good
> > testing matters. And for some other (mostly desktop software and
> > developer tools like the autotools, toolchain and debugger I forgot
> > to mention), having the latest version is imperative. By using
> > debian testing/unstable you give up on the first. By using debian
> > stable, you give up on the second. The only solution on Debian is to
> > compile testing packages on stable, but as I explained, even this
> > only available solution is made uselessly difficult by the control
> > files requiring newer versions of the libraries that they do not
> > actually strictly need. Compiling packages yourself is much easier
> > on other distributions.
>
> That's a matter of ones preference. I find building debian packages
> fairly simply. Redhat is complicated. Some distributions I guess you
> just build from source and throw it in and it's your problem to get the
> things that work together right. Some consider that easier.
Once again, no. Compiling a Debian testing package on Debian stable
is made stupidly painful by the fact that the average Debian testing
package control file requires the Debian testing versions of the
libraries it uses whereas in fact, it could very well compile with
the Debian stable versions. The result is that if you want to
compile the Debian testing version on a Debian stable, you end up
uselessly upgrading a lot of stable packages with testing ones, or
spending a lot of time compiling and recompiling a package to try
whether it could work with the Debian stable libraries.
>
> > I was rather referring to the conclusion of the mess.
>
> The conclussion and the entire progress towards it. I am not convinced
> it is even over yet.
In a few years from now, not using systemd on Debian will be
impossible, because the classical init scripts will not have been
tested (lots of users who want classical init systems have fled
Debian anyway, there is even a Debian fork without systemd, Devuan
?) and will have become rotten. I guess someone else probably said
that during the debate, so, it is pointless to even mention it.
>
> > > Not required to, but usually does submit upstream. Of course there are
> > > also cases of upstream being impossible to work with, or in some cases
> > > no longer exists. There are packages for which Debian has become the
> > > defacto maintainer because the upstream is no longer there.
> >
> > I do not think Xenomai was in either of these cases.
>
> I entirely agree. :)
That is not exactly true, my relations with the Debian maintainer
have been bad from the early start. But that is because very early
on, he started applying crappy patches behind our back.
>
> > I thought it worked well, and believed like you that problems came
> > from upstream packages, until I tried another one and found out it
> > worked better, so, the Debian problems definitely not all come from
> > the upstream packages.
>
> Well I know slackware, and I can't think of anything it does well,
> so unless you have some other distribution suggestions to look at,
> I am stuck with Debian. Oh well.
I guess it is a matter of preferences, so it is probably better not
to continue discussing. But what I find Slackware does well is that:
- it does not flood you with tons of distribution specific helpers,
there are a handful of such helpers on slackware, it has a
definitely simple design;
- it patches much less the upstream packages
- it has the split between a base of not-so-current stable system
base, with the possibility to install recent packages on top that is
ideal for me
- I find the slackbuilds, which are basically shell scripts, using
one unique helper, easier to work with than the Debian equivalent, the
debian/rules
- once done installing it, and doing the basic configuration, it
just works, and works well, especially KDE.
The other distribution I considered is archlinux, I have tried it a
bit on windows with the "msys2" system, and their wiki is really
great. The reason I did not go that way is that systemd is the
official init system of archlinux.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
