| 1 |
Dnia 2013-06-12, o godz. 18:37:08 |
| 2 |
Ulrich Mueller <ulm@g.o> napisał(a): |
| 3 |
|
| 4 |
> >>>>> On Wed, 12 Jun 2013, Tomáš Chvátal wrote: |
| 5 |
> |
| 6 |
> >> There was the argument that the unit file wasn't accepted upstream, |
| 7 |
> >> and I wouldn't dismiss this lightly. Often it's a cleaner solution |
| 8 |
> >> if files foreign to a package are installed by a separate |
| 9 |
> >> supplementary package. It avoids recompilation of the original |
| 10 |
> >> package by the user, for example. |
| 11 |
> |
| 12 |
> > So is openrc file. |
| 13 |
> > So is logrotate file. |
| 14 |
> > So are cron scripts. |
| 15 |
> |
| 16 |
> I was more thinking about support files for Emacs, where we do this |
| 17 |
> all the time: If the file is included with the upstream package, it's |
| 18 |
> being installed by that package's ebuild. Otherwise, it will go into |
| 19 |
> its own separate package. (And I guess it is similar for Vim.) |
| 20 |
|
| 21 |
That's very inconsistent and therefore problematic for users. Some |
| 22 |
packages work out-of-the-box, others require manually merging |
| 23 |
additional packages... |
| 24 |
|
| 25 |
I was thinking of trying to find a better way of providing support |
| 26 |
files. I thought about it for a minute then decide it's not really |
| 27 |
worth it. There's no simpler and more efficient way than just adding |
| 28 |
that tiny file to the package. |
| 29 |
|
| 30 |
Even if that sums up to 10 different files, no other solution can be |
| 31 |
better. If you introduce additional packages, the ebuilds, cache, vardb |
| 32 |
-- it is all going to take up more space than those installed files. |
| 33 |
|
| 34 |
-- |
| 35 |
Best regards, |
| 36 |
Michał Górny |
Archives