Whoops, hit reply too soon. To continue...... it is the lack of a satisfactory answer to that question that leaves me with the opinion that, even though Debian's stance on the Creative Commons licenses is really annoying, they are right damnit.
People (e.g., Debian) who want to distribute a program that is licensed under the GPL and that uses data files (icons, music, etc) that is licensed under Creative Commons licenses care.
An anonymous coward said some time ago,
When I looked at Zend's introduction to PHP, the first sample PHP program was Hello World, and the second was a cross-site scripting vulnerability.
Well if you feel that a package of your software with such reduced functionality would still be useful, and if you don't mind being inundated with support requests from users who install it from Debian's archive without realising its limitations then I would speak to M. Marillat (who I see is actually the maintainer of the package in the debian-multimedia.org repository) about getting such a package put together and uploaded into Debian proper. Anyway, this is really a discussion for the debian-mentors list.;)
You're not reading what I wrote. I said that mplayer had problems in the past, but that it has been cleaned up and is now in Debian main. But the version that is there has to be built without mencoder or any other encoding features, because of stupid software patent laws in the US, Japan, various European countries and possibly others.
You can use the web interface at http://packages.debian.org/ or run 'aptitude download'. Other apt-based software may also have an option to download packages instead of installing them.
Right, so without mplayer/mencoder the app is kind of crippled. If someone installed it from Debian's main archive and then tried to use it, would they really find it useful, or would they get frustrated and think the app was broken somehow? A lot of video software is in the same boat--in order to make it suitable for main, so much significant functionality has to be removed from the software as to make it pointless including it.
Wait a second, I just realied the mistake I made. I guess the problem is that your package encodes video (or depends on another program that encodes video), and so can't go into Debian because of the patents that Debian would then be violating.
Until the patents expire, I guess that you'll be stuck in the debian-multimedia.org repository.
If the software depended on mplayer then it did have legal problems as far as the project was concerned, unless someone wanted to hire a lawyer to prove that it did not. Unfortunatly, the project has to be boundby the laws of the countries in which it operates, and those laws (copyright & trademark) have very expensive consequences for those who violate them. But anyway, now that mplayer has been cleaned up and accepted into main, that is all in the past.
From reading your WNPP bug and your project's Download page, it seems that you already have functional packages. You just want to get them accepted into Debian. To do this, you need to find a Debian Developer who is willing to sponsor uploads of the package.
You already have the package in the debian-multimedia.org repository, which is run by Chris Marillat & a few other DDs (IIRC), one of them may be willing to help you out. If not, post an RFS (Request For Sponsor) message to the debian-mentors mailing list and see if that generates any interest.
There may also be a collaborative maintenence project for multimedia packages that would help with the maintenence of the package & manage uploads to the Debian archive; similar ones exist for other types of packages, for instance the Debian Games project.
I do agree that getting software included in Debian that no DD takes an interest in can be a pain in the arse. A few of my packages are in the same state that yours is in.:(
Well that is really a failing of the program. I wouldn't assume that all programs act like that though. These days, many programs are written to be 'relocatable' as the buzzwords go--i.e. they will run from anywhere that you extract them to. This was traditionally Not Done on unixoid systems because there was no (good) way for a process to discover the location of its executable file. On Linux, however, a process can examine the symlink at/proc/self/exe to discover where its executable is in the filesystem; from there it can find its data files. Other modern operating systems have a similar mechanism.
If the package contains multiple binaries and only one depends on LDAP/X then it is a perfect candidate to be split into multiple binary packages.
The same applies to vim. Debian builds multiple variants of vim depending on what you want: vim-tiny, vim, vim-gtk, vim-gnome, vim-full and a few others.
It really sounds like you should just use Debian;)
I really don't see what your problem is. You want to install a packag, that depends on the ldap client libraries. If you don't install those libraries then you won't be able to use the software... what would be the point of that?
Most well-written software is modular and doesn't require every single dependency to be installed at the same time. For example, the Foo software could be split into multiple binary packages (.debs; I am using the Debian terminology since that is what I am most familiar with) such as 'foo' containing/usr/bin/foo and 'foo-ldap' containing/usr/lib/foo/plugins/libfoo-ldap.so. Thus, if you didn't want Foo's ldap functionality, you would not install foo-ldap and the depended-upon libldap2.
It sounds like the software that you are trying to use is poorly written, or has been packaged in a way that does not allow what I described above. Perhaps you could give a specific example of a problem that you have run in to?
It's impossible to implement upgrades cleanly without reimplementing half of dpkg. Also you have the usual problem that you must ship a private copy of all the libraries you want to use, etc.
Except for the programs that don't use application bundles, precicely *because* they want to drop other files into other places on the filesystem.
What is the Mac OS X equivalent of dpkg --listfiles packagename? See, dpkg tracks all the files that are part of a package _for_ you. Nothing difficult about it.
How about apt-get upgrade? How about apt-get source?
No, just install libx11-6 & the other X libraries that are depended on. The only reason you would need the whole of X, server and all, is if your distibution was shit and didn't package the different components of X as separate packages.
Slashdot Mirror
Whoops, hit reply too soon. To continue... ... it is the lack of a satisfactory answer to that question that leaves me with the opinion that, even though Debian's stance on the Creative Commons licenses is really annoying, they are right damnit.
You make a lot of assertions, but you don't back them up. What is the real difference between software code and music/artwork/fiction text?
People (e.g., Debian) who want to distribute a program that is licensed under the GPL and that uses data files (icons, music, etc) that is licensed under Creative Commons licenses care.
Did you file a bug? A user program such as wine should not be able to lock the machine up! :)
Well if you feel that a package of your software with such reduced functionality would still be useful, and if you don't mind being inundated with support requests from users who install it from Debian's archive without realising its limitations then I would speak to M. Marillat (who I see is actually the maintainer of the package in the debian-multimedia.org repository) about getting such a package put together and uploaded into Debian proper. Anyway, this is really a discussion for the debian-mentors list. ;)
You're not reading what I wrote. I said that mplayer had problems in the past, but that it has been cleaned up and is now in Debian main. But the version that is there has to be built without mencoder or any other encoding features, because of stupid software patent laws in the US, Japan, various European countries and possibly others.
You can use the web interface at http://packages.debian.org/ or run 'aptitude download'. Other apt-based software may also have an option to download packages instead of installing them.
Right, so without mplayer/mencoder the app is kind of crippled. If someone installed it from Debian's main archive and then tried to use it, would they really find it useful, or would they get frustrated and think the app was broken somehow? A lot of video software is in the same boat--in order to make it suitable for main, so much significant functionality has to be removed from the software as to make it pointless including it.
Wait a second, I just realied the mistake I made. I guess the problem is that your package encodes video (or depends on another program that encodes video), and so can't go into Debian because of the patents that Debian would then be violating.
Until the patents expire, I guess that you'll be stuck in the debian-multimedia.org repository.
I do think that Debian should link users looking for updated software and multimedia software to http://backports.org/ and http://debian-multimedia.org/ more prominently (or even at all).
If the software depended on mplayer then it did have legal problems as far as the project was concerned, unless someone wanted to hire a lawyer to prove that it did not. Unfortunatly, the project has to be boundby the laws of the countries in which it operates, and those laws (copyright & trademark) have very expensive consequences for those who violate them. But anyway, now that mplayer has been cleaned up and accepted into main, that is all in the past.
:(
From reading your WNPP bug and your project's Download page, it seems that you already have functional packages. You just want to get them accepted into Debian. To do this, you need to find a Debian Developer who is willing to sponsor uploads of the package.
You already have the package in the debian-multimedia.org repository, which is run by Chris Marillat & a few other DDs (IIRC), one of them may be willing to help you out. If not, post an RFS (Request For Sponsor) message to the debian-mentors mailing list and see if that generates any interest.
There may also be a collaborative maintenence project for multimedia packages that would help with the maintenence of the package & manage uploads to the Debian archive; similar ones exist for other types of packages, for instance the Debian Games project.
I do agree that getting software included in Debian that no DD takes an interest in can be a pain in the arse. A few of my packages are in the same state that yours is in.
Well that is really a failing of the program. I wouldn't assume that all programs act like that though. These days, many programs are written to be 'relocatable' as the buzzwords go--i.e. they will run from anywhere that you extract them to. This was traditionally Not Done on unixoid systems because there was no (good) way for a process to discover the location of its executable file. On Linux, however, a process can examine the symlink at /proc/self/exe to discover where its executable is in the filesystem; from there it can find its data files. Other modern operating systems have a similar mechanism.
I suggest you re-read my post. Pay particular attention to the third word of the second line.
If the package contains multiple binaries and only one depends on LDAP/X then it is a perfect candidate to be split into multiple binary packages.
;)
The same applies to vim. Debian builds multiple variants of vim depending on what you want: vim-tiny, vim, vim-gtk, vim-gnome, vim-full and a few others.
It really sounds like you should just use Debian
I really don't see what your problem is. You want to install a packag, that depends on the ldap client libraries. If you don't install those libraries then you won't be able to use the software... what would be the point of that?
/usr/bin/foo and 'foo-ldap' containing /usr/lib/foo/plugins/libfoo-ldap.so. Thus, if you didn't want Foo's ldap functionality, you would not install foo-ldap and the depended-upon libldap2.
Most well-written software is modular and doesn't require every single dependency to be installed at the same time. For example, the Foo software could be split into multiple binary packages (.debs; I am using the Debian terminology since that is what I am most familiar with) such as 'foo' containing
It sounds like the software that you are trying to use is poorly written, or has been packaged in a way that does not allow what I described above. Perhaps you could give a specific example of a problem that you have run in to?
The packages *are* managed, by the *package manager*. What *is* the problem then?
Also avoid all that pesky OS integration! Who needs applications to integrade with their desktop anyway?
If you have to rely on debian-multimedia.org then the problem is probably a legal one rather than a technical/social one.
Not to mention https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=119185 which is still not really fixed.
"Not so hard"? Why does everyone use GCC instead of implementing their own compiler then?
It's impossible to implement upgrades cleanly without reimplementing half of dpkg. Also you have the usual problem that you must ship a private copy of all the libraries you want to use, etc.
Because you are fucked when one of the bundled libraries has a security vulnerability. You might as well statically link everything!
Except for the programs that don't use application bundles, precicely *because* they want to drop other files into other places on the filesystem.
What is the Mac OS X equivalent of dpkg --listfiles packagename? See, dpkg tracks all the files that are part of a package _for_ you. Nothing difficult about it.
How about apt-get upgrade? How about apt-get source?
How about apt-get upgrade?
No, just install libx11-6 & the other X libraries that are depended on. The only reason you would need the whole of X, server and all, is if your distibution was shit and didn't package the different components of X as separate packages.